在WebBrowser控件上页面导航后尝试执行JavaScript时出错

Question

I use a WebBrowser control in a WP7 app and have set IsScriptEnabled to true. Then when trying to invoke a script via InvokeScript of the WebBrowser I see a strange behavior: The script gets executed correctly on the first page. Then I navigate to another page via Navigate() and try to execute a script I get following error message:

"An unknown error has occurred. Error: 80020006".

I have tried to set IsScriptEnabled to true before navigating to the next page - no luck. Waiting for the completing of the document loading state doesn't help either.

All HTML files are stored in isolated storage and get displayed correctly. Only the script interaction doesn't work.

Any ideas?

Answer 1

--edit/quetz: If you have problems with on-page javascripts not running at all: make sure to check my findings on the subject that I've posted at http://social.msdn.microsoft.com/Forums/en-AU/jscript/thread/bac9f056-e0de-449e-a1b6-36e745fa59c6 - maybe your problems are related to some unlucky timings or property-setter ordering. it turns out that if you hardcode the URL in XAML, then you must ensure that in that XAML the IsScriptEnabled is set BEFORE the SOURCE property, or else you will have lots of failures depedent on what doctype your pages have. the same applies to setting the Source or Navigate'ing in the code, but that's quite obvious there. on the other hand, at first glance, bindings seem to work properly either way. --/edit

A long time since your posting passed, but if you still have the question in your memory, then maybe it will help you a little.

Let's first think shallow:

Maybe the page has not loaded yet? You say that all pages are on ISO, so they load in a blink of the eye, but still it takes some time. You only have pointed out the Navigate() method which is a little strange to me, because when InvokeScript()'ing, the most important thing is, to do the invokes it in- or after- receiving the Navigated event . While you might have it properly implemented, and you might have mistyped the Navigated-event with Navigate() - but according to what you've written, you also could have been trying to do:

void myfuntion()
{
    webbrowser.Navigate("pages/index.html");
    webbrowser.InvokeScript("myjsfunc");
}

which will almost never work. the proper way to implement it is:

...
    //elsewhere
    webbrowser.Navigated += wb_Navigated;
...

void myfuntion()
{
    webbrowser.Navigate("pages/index.html"); // or webbrowser.Source = ...
}

void wb_Navigated(object sender, NavigationEventArgs e)
{
    webbrowser.InvokeScript("myjsfunc");
}

only in this way you can be sure that the page has loaded. Without it, it's you are almost guaranteed to fail.

However, you would probably get a 0x80020101 hresult in such case.

That one, at least in the 7.0, 7.1 and 7.5 sdk releases, is used when the JS engine encounters a symbol is not understood. This error is also reported for many other cases, too, but this is the most common. Whenever you try to call enything that contains undefined names - you will see 0x80020101. For example, InvokeScript("eval", "askdjaslkdsajdla") will throw that, assuming this variable is not created to fool the example:)

I'm writing about that, because if you are NOT reacting to the Navigated and make calls prematurely, then the in-memory-page may still be the old-page with old-contents, and thus the names you try tu refer could be missing.

But, if you really see 80020006 (which is namenotfound but from OLE layer), then I'd assume the problem is elsewhere. Then, we have to dig deeper..

Whenever you try to call a InvokeScript during the Navigated-event-handler, then you might fall a victim to a very random (at least from my experience) bug in the webbrowser. Simply: sometimes, despite receiving 'Navigated' notification, the WebBrowser is not actually yet in a fully-prepared/rendered/wtf condition.

I dont know exactly when, I suppose it's connected to either the page size, scripts size/time, or amount of external linked resources.

When this happens you will be observing ComException other than 0x80020101, and I'm almost sure that it would be the 80020006. Simple InvokeScripts like ("eval", "mom") may execute and run correctly, but the more complicated it is, the smaller chances. For example, when it happens, ALL scripts referring directly to the body element, or its children - will instantly fail upon resolving that symbol. If you use libraries like jQuery - you may not event have the reference to body explicitly stated - if the library touches it, it will fail just in the same way, with the same exception. Strangely, the document.head is not affected by the problem it, and you may refer to it with no problems. From my observations, only the body is problematic in such cases.

Actually, after writing that - I see that probably your case is may exactly like that, as you try to modify 'document.body.style.fontSize'..

Anyways, there is no instant way to solve the problem, because the problem is somewhere in the internal timings of the webbrowser, and it happens to be reporting 'Navigated' too soon. I'm sure it is hideous a bug in the webbrowser, and maybe they will fixing in some future release. Until that, the only way to handle it, is ... to delay your invocation, until the browser really finishes parsing the page.

To say it in other words: If you are trying to properly call InvokeScript in the browser.Navigated handler, you may get an exception different than 0x80020101 (which would mean that your js-code given to InvokeScript is bad formed). If you catch such error (probably 80020006), then check whether you can 'touch' the document.body via the invokescript. if you get different error, then this is NOT the case. But, if you get the SAME error, then most probably it is the case, and the problem is your-or-webbrowser's unlucky timing. You have to abort your attempts, start a timer of 125..500 milliseconds, return from the handler so the browser will be allowed to continue its internal jobs, and then, when the timer elapses - retry the original call and pray. And during that delayed attept, you also must listen for exceptions in the same way, because you may get the same error again, and again, and again (..).

From my experiments, 500ms was always enough in such cases, but it was ugly for the user-experience. 125 was quite unnoticeable, but then - sometimes it was too quick, and 2-3 retries had to be done..

But, whatever happens - once you Navigate, receive Navigated, then successfully touch the document.body -- the timingerror will never occur again, for that page. Once the internal browser's gears get running, the InvokeScript will work like a charm, well, until you load next page.. ;)

From my experience, if you can control the raw source of the page, you may also try a bit simpler workaround - in your page, somewhere in the body, place:

<script type="text/javascript"> window.external.notify('somestringyouwillknow');  </script>

and in your C# or XAML code, attach to WebBrowser.ScriptNofity event. Whenever your that page loads, it will invoke that ScriptNotify and provide you with the string you have written there. It will surely arrive after the Navigated event, and if you catch such ScriptNotify notification - it is obvious that the JS engine has loaded and that the body is at least partially parsed, and probaly also the document.body will be initialized and touchable.

Answer 2

80020006 can be shown for a variety of reasons due to failing to execute the required function. Typically this is experienced when the function cannot be found.
Ensure that you are loading the correct version of the file which contains the function and not an old cached version.
Caching on the phone can be very aggressive so please don't assume that you have the latest version of the file loaded. When in doubt, change the files contents so that you can see that it is the latest/appropriate version.

Update
As it seems you're trying execute code against arbitrary pages that have been browsed to on the web you may be having the same issue as documented at http://social.msdn.microsoft.com/Forums/en-US/windowsphone7series/thread/e00942e4-e40c-4e80-b112-30ca0709fbc8/

This may also be related: http://social.msdn.microsoft.com/Forums/en-US/mktplace/thread/4ae5f139-f8b2-495b-860f-01075b735ee7/

Answer 3

Make sure all your pages have DOCTYPE tag, something like

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

I also found that including a piece of javascript, even an empty pair of tags helps as well:

<html>
    <head>
        <script></script>
        ...  
  <head>
  <body>
      ...
  </body>
</html>     

Answer 4

I've seen this error in three situations:

1. When there's a JavaScript error in the function in the page you are calling into. Try debugging the page in Chrome paying special attention to the inspector. You might need to add some scaffolding to play as your C# code during this debugging process.
2. When the WebBrowser control is not correctly attached to the XAML layout. For example, when the control is in a grid but does not have Grid.Row or Grid.Column attributes set or if they are out of bounds.
3. When using the WebBrowser.Loaded event instead of the WebBrowser.LoadCompleted event as the trigger for eventually calling InvokeScript()