We need to improve our link activation APIs enough that the features (Open in New Window, Open in New Tab) so that the features Firefox implements in front-end JS Code (which leads to bugs when there are differences in detection of what is a link, bugs where the two sets of link activation code handle links differently, etc.) can be implemented using those APIs. Having this stuff implemented in two different places has led to bugs and inconsistencies in the past. (I think even some security bugs, if memory serves correctly.) I think at least the way to start approaching this is by enhancing the current nsILinkHandler and nsILink interfaces. I'll attach a partial interface sketch most of which I emailed to bzbarsky a few months ago. The basic idea of these enhancements is the following: * they should be sufficient to remove all link activation code from the front end (currently present for things like Open in New Window, etc.) * they should be sufficient to allow the front end to request + single-window mode (in which all new-window or new-tab links are opened in the originating window) + tabbed-only mode (in which all new-window links are opened in a new tab instead) such that these modes work correctly for: + all "normal" URLs + javascript: URLs + onclick, onmousedown, etc., event handlers This actually shouldn't be too difficult, although it does require a bit of refactoring. The nice thing for the last bit (onclick, etc.) is that the existing popup-blocking architecture should provide us a nice place to attach exactly the information we need: in the same stack that says that popups are allowed, we can place information that they should be redirected into a new tab or stay in the same window. One tricky bit might be figuring out the best way to make the back end tell the front end to create a new tab and put something in it.

Hmm... So right now we basically convert link verbs to named targets, since that's what the window watcher speaks. We don't really want named targets for "force new tab" or "force same window" or "force new window"... What are the use cases for differentiating between tab and window here? Would we ever want to allow doing this in a way that overrides the user's prefs? Or in other words, could we get away with the following link verbs: * do nothing (easy) * activate normally (gets target from link node) * force in same window (target="_self") * force in new rendering area (target="_new"; whether this opens a new tab or window, or uses window.top or whatever is based on whatever rendering area nsIWindowProvider returns, per user prefs or whatever). ?

I don't see the use case for distinguishing between the two for default behavior: there "_new" should be sufficient, and a tabbed-only mode can just change what that means. But we do need to distinguish them for things like middle-click meaning open-in-new-tab, a context menu item that does open-in-new-window, or similar features.

Hmm.... OK. So yeah, then we need to give some way for Gecko to open new tabs or whatever as needed. One way might be to use the "new window" link verb and pass in an nsIWindowProvider or some similar object so that docshell can just ask it for the window to load into. Null provider means use window.open() with the target as we do now.

[sg:want P4] because this will help eliminate bugs where mail messages can show you one URL in the status bar when you hover but take you to another when you click. (Bug 266932 is one example.)

Note that some of the broken Firefox features that this would fix were disabled in bug 251137, which would need to be reverted for some of the benefits here.

We can also intercept location.href setting so it works for open in new tab/window.

Pretty much very XULRunner app needs this (if I'm not mistaken)

This issue still exists, and among other things it blocks is the ability to right-click on embedded or generated SVG images so they can be saved to disk, an ability IE *does* have. It's a pretty sorry state of affairs when IE can do something simple that FF can't. Now that bug 365813 is fixed, there isn't any good reason why this bug is still open.

re comment 11: this bug is about deciding that a link activation should go to the same window vs. a new tab vs. a new window, not about what the "new tab" or "new window" should mean. That belongs in a separate bug.