This is a request for new API. When I want to develop an addon which provides ability to invert actions for links (left-click => new tab, Ctrl-left-click or middle-click => current tab) there is no way. "Left-click => new tab" is possible by overriding "target" attribute of clicked links by mousedown event, but "Ctrl-left-click or middle-click => current tab" is impossible because Firefox is designed to open links by those actions in new tab always. Thus, I need something API to interrupt and rewrite the result of Firefox's `whereToOpenLink()` ( http://mxr.mozilla.org/mozilla-central/ident?i=whereToOpenLink ). These my addons require this API: https://addons.mozilla.org/firefox/addon/open-link-in-new-tab/ https://addons.mozilla.org/firefox/addon/open-bookmarks-in-new-tab/ https://addons.mozilla.org/firefox/addon/new-tab-from-location-bar/ Some of them gave up to provide the feature "middle-click => current tab" when migrated to e10s, because it is impossible for now. This requested API will restores their functionality, and it will help other addons like Tab Mix Plus.

Of course `whereToOpenLink()` is just the current implementation, and will be renamed in the future. This requested API will work around something similar to the functionality of `whereToOpenLink()` in future Firefox.

I think "chrome.webRequest" filters will become the baseline of this idea.

This has been added to the May 9 WebExtensions API triage. Piro, would you be able to join us? Wiki: https://wiki.mozilla.org/Add-ons/Contribute/Triage Agenda: https://docs.google.com/document/d/1q7UD3DxsT5z0lO3EbOyF9Iln32Wg_e9LYMdHZ80BEb4/edit#heading=h.du5ihvu5p6ro

(In reply to Caitlin Neiman (http://pronoun.is/she) from comment #3) > This has been added to the May 9 WebExtensions API triage. Piro, would you > be able to join us? OK, then I'll join to IRC channel.

Updated API proposal: This proposal means to add something new features to webRequest.onBeforeRequest and around. https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/webRequest/onBeforeRequest https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/webRequest/onBeforeRequest#Parameters As described here, a listener will return an webRequest.BlockingResponse. https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/webRequest/BlockingResponse Currently webRequest.BlockingResponse is designed mainly for cancelling or redirecting the request. I think it should have some new properties: * "whereToOpen" to control the location where the request is opened in. Possible values: - "current": in the current tab, in the current frame - "existingTab": in an existing tab - "foregroundTab": in a new foreground tab - "backgroundTab": in a new background tab - "window": in a new window - "save": save to a file * "tabId" to control the tab where the request is loaded in. - This works only when "whereToOpen" is "existingTab". - Possible value is: a tab ID. * "windowId" to control the window where the new tab is opened in. - This works only when "whereToOpen" is "foregroundTab" or "backgroundTab". - Possible value is: an window ID. https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/webRequest/onBeforeRequest#details As described here, a listener will receive a details object to determine how treat the request. I think it also should have a new property: * "trigger" to indicate what action triggers the request. This is an object with these properties: - "type", possible values: + "link": means triggered by click or tap on a link. + "script": triggered by "window.open()" in the webpage. + "addon": triggered by another addon, via any other WebExtensions API. - "ctrlKey": boolean, available when "type" == "link". - "shiftKey": boolean, available when "type" == "link". - "altKey": boolean, available when "type" == "link". - "metaKey": boolean, available when "type" == "link". - "isLong": boolean, available when "type" == "link". This means that it is a long tap. It is required to determine the "whereToOpen" of the webRequest.BlockingResponse. Of course, Other existing properties (tabId, parentFrameId, etc.) are also useful.

When "whereToOpen" is "save", the addon author can specify expected location of the saved file. It is optional, and a common file dialog (like "save to a file") will appear by default when no extra file information is given. Or, the file possibly saved into the download folder silently. The result will depend on the preference of Firefox itself. And, when "whereToOpen" is not given, it will mean "whereToOpen"=="current" by default.

More possible values for the "trigger.type": * "bookmark": a bookmark item. * "history": a history item. * "notify": a desktop notify or a push notify on Android.

On IRC: > 02:38 (jorgev) that bug was denied. The main reason is that WebExtensions > making UI changes should make those changes obvious to the user. Since > this is a very hidden kind of change, it wouldn't fit as a WebExtensions API This comment seems mismatched to some existing APIs, especially webRequest.BlockingResponse itself. https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/webRequest/BlockingResponse It is clearly designed to work silently with no UI. Why it is still allowed but mine is denied? Just for backward compatibility? Anyway I'm waiting for Andy's comment.

You are right, webRequest allows you to mess with Firefox and it does not have any clear user interaction. However without webRequest we wouldn't have much of an extension ecosystem, being able to interact and potentially block requests is something we can't live without. We've tried to make every other API to make it clear to the user why something has happened, which is why context menus get an icon from the add-on, the sidebar API links back to the add-on and so on. Just because we've got webRequest doesn't mean we shouldn't stick to our principles and make Firefox as understandable as possible. Additionally, in the meeting there were also comments saying that webRequest or webNavigation are not the right place for this to live. If I understand your request as an example, if I middle clicked on a link, this API could route it to one of the locations. Or as another example if I right click and then click on "Open Link in New Tab" and it goes to something completely different, there's no indication of why that happened to the user. The benefit of putting this API in does not outweigh the usability problems we are concerned about or the cost of maintenance.

@comment 1: "When I want to develop an addon which provides ability to invert actions for links (left-click => new tab, Ctrl-left-click or middle-click => current tab) there is no way. "Left-click => new tab" is possible by overriding "target" attribute of clicked links by mousedown event, but "Ctrl-left-click or middle-click => current tab" is impossible because Firefox is designed to open links by those actions in new tab always." This seems possible for page links, at least, using a content script with |MouseEvent.preventDefault| in conjunction with |Location.assign|, |browser.tabs.create| with the |createProperties.active| argument, and |browser.windows.create|.

Thank you for the detailed description of the decision. (In reply to Andy McKay [:andym] from comment #9) > If I understand your request as an example, if I middle clicked on a link, > this API could route it to one of the locations. Or as another example if I > right click and then click on "Open Link in New Tab" and it goes to > something completely different, there's no indication of why that happened > to the user. > > The benefit of putting this API in does not outweigh the usability problems > we are concerned about or the cost of maintenance. I agree that my idea dropped some viewpoints as you described. I've realized that my actual demand is: "I don't want to reuse the current tab for bookmarks, histories, location bar, etc." I'll try to reconstruct my addons to solve the point based on existing APIs. (In reply to Patrick Dark from comment #10) > This seems possible for page links, at least, using a content script with > |MouseEvent.preventDefault| in conjunction with |Location.assign|, > |browser.tabs.create| with the |createProperties.active| argument, and > |browser.windows.create|. Thank you for suggestion. However, to be honest, the feature was not fit to my actual use case described above. I think that I should give up to develop the "Open Link in New Tab" addon by myself, and I just leave the repository for people who really want it.

(In reply to Patrick Dark from comment #10) > @comment 1: "When I want to develop an addon which provides ability to > invert actions for links (left-click => new tab, Ctrl-left-click or > middle-click => current tab) there is no way. "Left-click => new tab" is > possible by overriding "target" attribute of clicked links by mousedown > event, but "Ctrl-left-click or middle-click => current tab" is impossible > because Firefox is designed to open links by those actions in new tab > always." > > This seems possible for page links, at least, using a content script with > |MouseEvent.preventDefault| in conjunction with |Location.assign|, > |browser.tabs.create| with the |createProperties.active| argument, and > |browser.windows.create|. Yes, unless a website does some weird Javascript stuff. I am just trying to tackle this problem for https://github.com/sblask/webextension-open-tabs-in-foreground It mostly works, but not on www.sueddeutsche.de because the site captures mousedown for the left mouse button and apparently does a window.open somewhere that I don't manage to stop.