I am hosting a webbrowser control, that usually loads an external documents, then makes some modifications using HTML DOM.
We also embed custom application links using a fake protocol, such as “Close This” that are caught and handled in BeforeNavigate2.
When the link tarket is misspelled (say, “spp:CloseWindow”), BeforeNavigate will not trigger custom handling. The Browser control does not show an navigaiton error, but remains in READYSTATE_INTERACTIVE and doesn’t fire a NavigateComplete or DocumentComplete.
My Problem:
Most operations (e.g. retrieving or updating the contents) are delayed and wait for the readystate reaching READYSTATE_COMPLETE. After such an invalid link is clicked, the browser doesn’t get updated anymore – a state I’d like to avoid.
How can I do that?
- Can I detect in “DownloadComplete” that navigation failed?
(So I could relax the test to"READYSTATE_COMPLETEorREADYSTATE_INTERACTIVE and last downloadComplete was broken“) - Can I “reset” the browser control to READYSTATE_COMPLETE (probably not)
- Could I detect the pseudoprotocols actually supported by the browser?
(In hindsight, using an xxxx: prefix wasn’t such a good idea, but changing that now is a bit of a problem.)
Internet Explorer and Windows have an extensible list of available protocols implemented in UrlMon.dll, I believe. See here for a bit about IE architecture.
The reason you cannot detect the bad protocol in BeforeNavigate is that the protocol is unknown, so no real navigation is happening. The browser decides to show an error page instead. Error page navigation does not evidently raise all the normal events.
However, there is a way to detect when navigation has gone in the weeds. If you hook up to the web browser’s DocumentCompleted event, you can scan for particular URLs associated with errors, or more generally, anything with a URL that starts with res://ieframe.dll.
Examples:
A cleaner way is to hook into the NavigateError of the DWebBrowserEvents2 interface.