views:

979

answers:

2

I have a Windows app that embeds the IE WebBrowser control, and runs a local webserver to serve content it. The URLs I load in are only meaningful within the application, and not valid after the application exits. They're never visible to the user. They look like this:

http://127.0.0.1:1234/something.html

where 1234 is a random port number for that session.

But these URLs are appearing the IE browser's address bar history - when I type "1" into Internet Explorer's address bar, a dropdown appears with all my URLs in it. They are useless in that context.

So, my question is: how do I prevent my URLs polluting that dropdown?

A little more information: I'm loading the URLs using window.location.href = URL, rather than via the Navigate method, so navNoHistory isn't an option (and I think that refers to the Back/Forward history anyway).

I've also tried deleting the URLs after the fact using IUrlHistoryStg::DeleteUrl(), but it doesn't work (it returns success but has no effect) - any tips on making that work would be gratefully received.

A: 

My original answer was the exact opposite of what you wanted.

I cannot replicate what you are experiencing but I am not using a Browser Control.

I would try adding a script to the html or a hidden frame/iframe and wrap the call so the browser executes it in the wrapper script.

Script based Navigates should not enter history, it took me awhile to come up with a way to hack IE to actually add history items with the click() event trigger from my original answer.

<script>
    function GoTo(url) {
        location = url;
    }
</script>
Chad Grant
You mean that preventing the **on-screen display** of the link -- i.e. the moral equivalent of changing the font -- prevents it from being added to the History? That is too weird!
j_random_hacker
actually, I just remembered this was for the exact reverse of the question. I actually had problems making IE history show up in IE history with script, I'll try to fix the code if I can remember it. The security demo secretly downloaded url's without the user's knowledge and effectively "framing" the user by entering all the trace info IE history, ISP and server logs. Unauthorized access to the /admin/ directory for example.
Chad Grant
OK, that's kind of a relief actually :)
j_random_hacker
I'm pretty much doing "location = url" at the moment, and the URLs are going into the history.
RichieHindle
and I couldn't get them in the history. strange
Chad Grant
+2  A: 

I've now made this work with IUrlHistoryStg::DeleteUrl() - if you call it immediately after asking the control to load a URL, it doesn't work. I'm guessing that's because the control doesn't add the URL to the history until it's finished loading the document.

By calling IUrlHistoryStg::DeleteUrl() later on, I can remove the URLs from the history.

I'd still rather they didn't get there in the first place, though.

RichieHindle