1400264 - WebExtensions browser.tabs.create() creates extra tabs in popup windows when it shouldn't (Screenshots links in a popup window open in the popup)

Status: RESOLVED DUPLICATE of bug 1415913

(WebExtensions :: Frontend, enhancement, P3)

Description

[Mike Kaply [:mkaply]]

If you open a popup window (gmail compose->shift on arrow is easiest) and then use screenshots (My shots or save), you get a new tab in the popup window.

It should open in the main window (we shouldn't do tabs in popup windows).

Comment 1

[:Gijs (he/him)]

AFAICT this is using browser.tabs.create() in the backend (cf. https://github.com/mozilla-services/screenshots/blob/ae5ac734d03cceb40ff7d1511e967f040a4b2a13/addon/webextension/background/main.js#L208 , https://github.com/mozilla-services/screenshots/blob/ae5ac734d03cceb40ff7d1511e967f040a4b2a13/addon/webextension/background/takeshot.js#L57 , etc.). That should be doing the right thing.

Andy, can we get this prioritized within webextensions? This likely affects other add-ons as well.

Comment 2

[Andy McKay]

Can it check https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/windows/WindowType and see if the type it popup before deciding where to open the tab? Presumably it could ask the screenshots content script what window is the opener and then open the window there.

I'll file a bug on github for that: https://github.com/mozilla-services/screenshots/issues/3507

Because there's a workaround, I'm not setting this too high a priority.

Comment 3

[Thomas Oberndörfer]

Also running into this problem with Mailvelope. I see the workaround in comment #2 but I just want to mention that the behavior of browser.tabs.create() in Firefox is currently not compatible to Chrome. When you call chrome.tabs.create() with an active popup window, Chrome will still open a new tab in the opener window.

Comment 4

[Thomas Oberndörfer]

According to my tests this is fixed in Firefox 59.0b9.

Comment 5

[:Gijs (he/him)]

(In reply to Thomas Oberndörfer from comment #4)
> According to my tests this is fixed in Firefox 59.0b9.

Good catch, this was fixed in bug 1415913.