Browser.HtmlPage.Window.Navigate is blocked but HyperlinkButton isn't - why?

I have a certain UI element, which when clicked should navigate to another URL. I tried handling the mouse down event and execute something like this: System.Windows.Browser.HtmlPage.Window.Na开发者_高级运维vigate(new Uri("http://google.com"), "_blank");

However, this gets blocked by the browser (I tried both Chrome and Firefox) unless I disable the popup blocker. I did some research and it seems that the browser blocks navigations that don't occur as a result of user interaction and as far as the browser is concerned this navigation is initiated by a plugin (Silverlight), not a user.

OK, makes sense. But then I tried using a HyperlinkButton instead and it was NOT blocked.

I wonder why these two approaches get different treatment from the browser. Any idea?

I actually worked around the problem by wrapping the navigation triggering UI with a HyperLinkButton, but I'm still very curious...

---

I'm going to pull a fancy corporate quote and say "It is a feature, not a bug."

The Silverlight team is obviously worried about Security. They don't want crazy haxorz like you and I to do crazy things with our apps--you know, like popping up a bunch of browser windows all routing people to Zombo.com. Just imagine the choir! Zombo!

Summarized from their documentation: They want us to only use the HyperlinkButton to go outside of their application. In fact, they went the extra step, and depending on our settings, they will even throw a SecurityException for us if we navigate to an outside page--Even from a HyperlinkButton. How nice.

The real question: Why the Hyperlink Button and not something else?

Only one "thing" can navigate. this take saves time for Microsoft while testing Silverlight. This one thing can navigate to both internal XAML pages and external web pages--Might as well be consistent and have only one way to do navigation.

It is a UIElement. It's code behind likes to run in the primary visual thread. It can promise the browser that a Visual Element wants to go somewhere. Microsoft can also put its limiting logic in a control that requires a mouse-click/keyboard-input event tree.

All in all, it makes sense to start simple by making a control do the work.

Fun stuff! Hope this helps you.