1653537 - In WebExtension, window.open(moz-extension://..., name) cannot set window name

Status: RESOLVED WONTFIX

(WebExtensions :: General, defect, P2)

Description

[CoolCmd]

Attachment: bug2.zip

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

1. install attached extension.
2. open https://example.com/
3. click the page. a new tab should open.
4. switch to this tab.
5. open the F12 console and check window.name value.

Actual results:

window.name === ""

2 clicks open 2 tabs.

Expected results:

window.name === "bug2"

2 clicks should open 1 tab (like in Chrome 84).

Comment 1

[Alexandra Martin]

Hi,

Thank you for taking the time to submit this bug report. After testing on Windows 10 x 64 bit and MacOS 10.14 with Nightly 80.0a1 (20200720094507), Beta 79.0b9 (20200717001501) and Release 78.0.2 (20200708170202), I managed to reproduce the issue that you described.

I've tried two times to get a regression range, but on the first build launched from the application (Nightly 68.0a1 (20190405214926) and Nightly 72.0a1 (20191120234543) in my case), I get "bug2" when checking the window.name value, but I still got different tabs, each time I was clicking on the example.com page, so I couldn't really continue, because I didn't know if those builds were a fail or pass. Which one of the actual results are more important in this case, or do both matter? Maybe there are two issues here, one for the window.name value and one for the several tab openings.

Comment 2

[CoolCmd]

the main problem is the number of open tabs. so, on 68, the browser sets the name but does not use it.

Comment 3

[Alexandra Martin]

Attachment: Nightly 58.0a1 (20171014220542).png

Hi again,

Thank you for the quick response. I tried again to find a regression range for the number of open tabs and I was still reproducing the issue on Nightly 59.0a1 (20171122220056), so the issue is probably older than that or maybe it wasn't implemented (not sure about that though). In Nightly 58.0a1 (20171014220542) and older versions, I couldn't install the add-on to see how much further the issue goes.

I also tried to find a regression range for the window.name value and I was more successful here. From the bisection I managed to narrowed it down to https://bugzilla.mozilla.org/show_bug.cgi?id=1629441 (2020-07-21T18:39:18.315000: DEBUG : Found commit message: Bug 1629441 - Defer to DocumentChannel in shouldLoadURLInThisProcess r=kmag) with the differential revision: https://phabricator.services.mozilla.com/D71331.

This is the corresponding pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9226f5b0d05bea99caf4f2f2119b47c0dadf6c69&tochange=272e82616218411bfb0b89ef7c710cd65830ece1.

Comment 4

[Tomislav Jovanovic :zombie]

Hey Paul, it looks like this is related to Bug 1629441, can you please take a look?

Comment 5

[Paul Bone [:pbone]]

Taking a look now. Thanks.

CCing kashav because he's working on related stuff now.

Comment 6

[Paul Bone [:pbone]]

I think I can work around the window name thing, however the other part with opening the window once or twice might be a pre-existing compat problem.

Kmag. The extension attached on this bug opens the window with:

document.addEventListener('click', e =>
{
    e.preventDefault();
    window.open(chrome.runtime.getURL('coolcmd.html'), 'bug2');
});

AIUI for non-extensions JS this should open only one window and refocus it the second time it is called. is that also true for extensions. The reporter says this is how chrome behaves.

It looks like what's happening here is that we drop the window name during process switching (web to extension). By making that process switch early rather than via document channel it works around the issue. I though that with BC preservation it would also keep the name but it seems it has no effect.

Next I'll look at trying to get BC preservation to handle it, but we'll probably need the workaround anyway since BC preservation isn't ready.

Comment 7

[Paul Bone [:pbone]]

As best as I can determine Firefox has never handled named windows from an extension properly (from what has been reported elsewhere on this bug, I suspect no-one tested it until now).

On this bug I propose to fix setting the name on the new window. However the duplicate opened windows (which appears to have a separate cause) I'll file a new bug.

Comment 8

[Paul Bone [:pbone]]

Attachment: Bug 1653537 - Perform an early process switch for EXTENSION_REMOTE_TYPE r=kmag

This is a work around as it avoids documentchannel. Hopefully we won't need
it after BC preservation lands.

Comment 9

[Paul Bone [:pbone]]

There was some discussion on Matrix about this a couple of weeks ago, that we may not be able to named targeting working, even if we keep named windows working since these windows are by necessity in different browsing context groups.

I want to follow up on that and ask why it works when we do the early process switch like in the work-around bug report. Does it not change browsing context groups in that case? (I'd say it should but we all know that path will go away).

PS: Can we do conversations over bugzilla/e-mail since Matrix is not very good at async and this conversation ocured at about 5:45am my time.

Comment 10

[Paul Bone [:pbone]]

TODO: myself, Add a follow-up bug to remove the work-around (not adding that bug now because we'll probably abort this one).

Comment 11

[Paul Bone [:pbone]]

Okay, there's a bit more information in Bug 1655903 comment 2.

I'm going to close / make these bugs a low priority since it's not feasable with the architecture we want.