Open Bug 335963 Opened 15 years ago Updated 4 years ago
better link activation API
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.)
Whiteboard: [sg:want P4]
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.
You need to log in before you can comment on or make changes to this bug.