1357845 - window.open opening multiple windows with same window name

Status: RESOLVED WONTFIX

(Core :: DOM: Core & HTML, defect)

Description

[Gavin Evans]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20170323105023

Steps to reproduce:

We have an intranet site which remains unchanged for years.  Firefox we believe since v52 is giving duplicate windows rather than refreshing existing.  IE/Chrome are fine.


Actual results:

Multiple windows opened when the current one should be refreshed.


Expected results:

A lot of great thoughts and reproduction have been done by jscher2000 on the support forum - https://support.mozilla.org/t5/Firefox/window-open-opening-multiple-windows-with-same-window-name/m-p/1392481#M1048127 - Perhaps you can review that as it is reproducable.  He says... "I played with this a little bit and in my testing, the ability to re-use a named window was per tab. I could re-use a window over and over from the same tab, even if I reloaded the page manually bypassing the cache. But if I launched the identical page in a second tab and ran window.open(), the window name is not unknown and a new one is generated.
 
I didn't test any previous versions, but I'll take your word that something changed in Firefox 52. The only change I saw related to window.open() on the release notes was the implementation of a new noopener "feature" that prevents the new window from accessing the window.opener property. https://developer.mozilla.org/Firefox/Releases/52#DOM I don't see why that change would cause the issue, but perhaps this is some collateral damage from a change made in the process.

I think the underlying question is whether this was an intentional (but poorly documented) change related to better tab isolation for security or performance reasons, or whether it was an accident. Hard to know!"

Comment 1

[Vlad Bacia-Mociran [:VladB]]

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

I have tested your issue on latest Firefox release v53.0 and latest Nightly (Build ID: 20170423030206) and could not reproduce it due to the lack of testing steps. Please provide more detailed testing steps.

Is this still reproducible on your end ? If yes, can you please retest this using latest FF release and latest Nightly build (https://nightly.mozilla.org/) and report back the results ? When doing this, please use a new clean Firefox profile, maybe even safe mode, to eliminate custom settings as a possible cause (https://goo.gl/AR5o9d). 

If this issue is reproducible for you, then you can use the Gecko Profiler to establish a regression range and maybe the fix/bug that introduced this issue. More info is available here: https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler and https://perf-html.io/ . please provide a regression range. Thank you

Comment 2

[Gavin Evans]

Firefox v53.0 has the same issue.  Unless you 'really' need me to test on the nightly build I'd prefer not to.

I've reproduced the issue with the profiler.  systemalerts.asp is the window which gets duplicated.

https://www.dropbox.com/s/acv7zxphoiu44lk/Gecko%20Profiler%20output.zip?dl=0 - I have shared the output of the profiler here.

Let me know if I can do anything else to help.  I can probably provide simple sample HTML pages if needed.

Thanks so much

(In reply to Gavin Evans from comment #0)
> User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
> Firefox/52.0
> Build ID: 20170323105023
> 
> Steps to reproduce:
> 
> We have an intranet site which remains unchanged for years.  Firefox we
> believe since v52 is giving duplicate windows rather than refreshing
> existing.  IE/Chrome are fine.
> 
> 
> Actual results:
> 
> Multiple windows opened when the current one should be refreshed.
> 
> 
> Expected results:
> 
> A lot of great thoughts and reproduction have been done by jscher2000 on the
> support forum -
> https://support.mozilla.org/t5/Firefox/window-open-opening-multiple-windows-
> with-same-window-name/m-p/1392481#M1048127 - Perhaps you can review that as
> it is reproducable.  He says... "I played with this a little bit and in my
> testing, the ability to re-use a named window was per tab. I could re-use a
> window over and over from the same tab, even if I reloaded the page manually
> bypassing the cache. But if I launched the identical page in a second tab
> and ran window.open(), the window name is not unknown and a new one is
> generated.
>  
> I didn't test any previous versions, but I'll take your word that something
> changed in Firefox 52. The only change I saw related to window.open() on the
> release notes was the implementation of a new noopener "feature" that
> prevents the new window from accessing the window.opener property.
> https://developer.mozilla.org/Firefox/Releases/52#DOM I don't see why that
> change would cause the issue, but perhaps this is some collateral damage
> from a change made in the process.
> 
> I think the underlying question is whether this was an intentional (but
> poorly documented) change related to better tab isolation for security or
> performance reasons, or whether it was an accident. Hard to know!"

Comment 3

[Vlad Bacia-Mociran [:VladB]]

(In reply to Gavin Evans from comment #2)
> Let me know if I can do anything else to help.  I can probably provide
> simple sample HTML pages if needed.

If you could provide a simple test case with steps it would be awesome. I'll do the regression range and test this further. Also feel free to use https://jsfiddle.net/ if the tools provided here are enough for you to give us a test case for the issue you are encountering or attach the testcase to this bug.

Comment 4

[Gavin Evans]

Hi Vlad... pls try this...  https://www.dropbox.com/s/r2yfpvfrhac6btq/testfiles.zip?dl=0  it's as close and as I can get it in terms of behavior.

If you load test.html in one tab, press the 'TEST' button, a new window appears.  You click 'TEST' again and it refreshes. 

This works fine.  BUT if you then repeat the process in a new tab, you then get another window appear where what should happen is the original window (with the date/time) is refreshed.

Does that help?

Gavin

(In reply to Vlad Bacia-Mociran [:VladB], Desktop Engineering QA from comment #3)
> (In reply to Gavin Evans from comment #2)
> > Let me know if I can do anything else to help.  I can probably provide
> > simple sample HTML pages if needed.
> 
> If you could provide a simple test case with steps it would be awesome. I'll
> do the regression range and test this further. Also feel free to use
> https://jsfiddle.net/ if the tools provided here are enough for you to give
> us a test case for the issue you are encountering or attach the testcase to
> this bug.

Comment 5

[Gavin Evans]

Attachment: test files

Comment 6

[Gavin Evans]

Attachment: test files pt2

Comment 7

[fromm]

Tested on nightly and still behaves as OP describes.  The named window is always opened new when a new tab or window that spawns it is opened.  Behavior before 52.0 was that the existing named window would be refreshed.

Comment 8

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Hi :VladB, Gavin has provided us test cases. Would you please help find a regression range? Thank you.

Comment 9

[Alice0775 White]

Attachment: test files(url modified)

Comment 10

[Alice0775 White]

(In reply to Gavin Evans from comment #4)
> BUT if you then repeat the process in a new tab, you then
> get another window appear where what should happen is the original window
> (with the date/time) is refreshed.


However, Firefox52+ is match Chrome58 behavior now. Named popup window is associated its parent tab. I think this is correct behavior.


Steps to reproduce:
1. Open attachment 8863585 [details] in Tab[1]
2. Click [TEST]
   --- new small window opens as expected
3. Open New Tab[2]
4. Open attachment 8861420 [details] in the Tab[2]
5. Click [TEST]
   --- observe pop up window


Actual Results:
Firefox52+:
   Another new small window opens.  And this is match Chrome58 behavior.

Firefox51:
   Existing small window is reused. the behavior different from chrome.

Comment 11

[Alice0775 White]

Sorry, Typo in str step4

Steps to reproduce:
1. Open attachment 8863585 [details] in Tab[1]
2. Click [TEST]
   --- new small window opens as expected
3. Open New Tab[2]
4. Open attachment 8863585 [details] in the Tab[2]
5. Click [TEST]
   --- observe pop up window

Comment 12

[Alice0775 White]

The new behavior(52+) is introduced by Bug 1303196( https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=3f15ff10cb267d4289655b2e3cf0a0dee48e7c0b&tochange=2a31079dae258444321138690fa68de6b3ddf06a ).

I think the new behavior(52+) is correct.

@:mystor,
What do you think?

Comment 13

[Nika Layzell [:nika] (ni? for response)]

Yes, this behavior change is known and intentional. It was made to avoid the confusing multi e10s behavior of windows being namespaced by process, and instead namespaced them by unit of related browsing contexts. This change also enables the scheduling work we are doing for quantum DOM.

Comment 14

[fromm]

This is not what Chrome Version 58.0.3029.81 (64-bit) does.  The same named window is refreshed with every new tab or window that writes to it in Chrome 58.

Since Firefox 52, all developers in our company have switched to Chrome because this behavior in Firefox is distracting.  We have a PHP debug tool that writes session variables, etc to a 'debug' window.  This change in Firefox 52+ makes it impossible for us to work.

Comment 15

[Nika Layzell [:nika] (ni? for response)]

Pinging bz for opinions on this.

Comment 16

[Boris Zbarsky [:bzbarsky]]

> The same named window is refreshed with every new tab or window that writes to it in Chrome 58.

That doesn't seem to be true.

Specifically, I created this document:

  <input type="button" onclick="window.open('https://example.com', 'hey')" value="click me">

and loaded it in a tab in Chrome.  Then I opened a new tab (with Cmd+t on Mac), and loaded the document in that tab.  Then I clicked the buttons in both tabs.  I got two separate windows opened, which matches my understanding of how Chrome does this stuff.  Comment 11 has steps to reproduce with pretty much that testcase

Note that if you have a lot of tabs already open (more than the number of processes Chrome is willing to start), then multiple unrelated tabs can end up in the same process.  It's possible that in that situation two tabs that are in the same process can target each other's windows in Chrome, though I thought they didn't do that...

Obviously, if the new tabs are being opened via some mechanism other than the browser's "open a new tab" UI, that would affect the behavior.

Gavin, what behavior do you see in Chrome when following the steps from comment 11?  In your actual use case (your intranet site), how are the relevant tabs being opened?

Comment 17

[fromm]

You're absolutely right.  If you manually open a new tab or window and go to the URL directly, Chrome continues to spawn the named window.

Our use is a bit different than the test files submitted here.  In Chrome, if you click a link into a new window or tab from the window that originally spawned the named window, it refreshes the named window.  Visit http://www.omnis.com/mozilla/test.html for a demonstration.  It will spawn a new tab/window named 'new'.  Shift or ctrl clicking the link will load the same page in a new window or tab and the existing 'new' window will be refreshed.

Comment 18

[Nika Layzell [:nika] (ni? for response)]

(In reply to fromm from comment #17)
> You're absolutely right.  If you manually open a new tab or window and go to
> the URL directly, Chrome continues to spawn the named window.
> 
> Our use is a bit different than the test files submitted here.  In Chrome,
> if you click a link into a new window or tab from the window that originally
> spawned the named window, it refreshes the named window.  Visit
> http://www.omnis.com/mozilla/test.html for a demonstration.  It will spawn a
> new tab/window named 'new'.  Shift or ctrl clicking the link will load the
> same page in a new window or tab and the existing 'new' window will be
> refreshed.

I think what this means is that their unit of namespacing is slightly different from ours. When we ctrl-click on a link, we load the new link in a separate TabGroup. As we use TabGroups as the unit of window namespacing, this means that the new window will not open into the same window as the previous one. 

It appears as though chrome uses a different form of window namespacing, where new windows opened with ctrl-click are in the same namespace as the original window. I'm not sure if this behavior is intentional, or a result of current architectural decisions, as it theoretically means that two "unrelated" windows (opened with ctrl-click) can need to be loaded in the same process as they can both obtain references to a common target window through window.open.

From my small (and probably inaccurate) experimentation, it appears as though chrome's unit of namespacing is based on both whether the windows are in some way related (via ctrl-click or window.opener, non web-visible relationships seem to matter), as well as by origin of the toplevel window.

It could be that this namespacing was decided upon as a result of websites such as fromm's breaking if our namespacing decisions were made. Changing our behavior to match the older behavior more closely would likely be fairly easy, we would just have to make ctrl-click force the new tab into the same TabGroup as the current tab. The question is how desirable it is.

Comment 19

[Boris Zbarsky [:bzbarsky]]

I think the best course of action for the moment is probably:

1)  Make ctrl-click use the same tabgroup for now, possibly behind a pref.
2)  Talk to the Chrome folks to find out whether their behavior here is purposeful or just
    fell out of the way things happened to be coded.

Using separate tabgroups for ctrl-click is obviously better in terms of performance and user experience in all cases when named targeting is not being used.  So we may want to have the pref and at some point default to the "separate tabgroup" behavior, with a release note telling people they can toggle the pref if they really need to...  Not sure how discoverable that would be anyway.  :(

Comment 20

[Gavin Evans]

Further to "Gavin, what behavior do you see in Chrome when following the steps from comment 11?  In your actual use case (your intranet site), how are the relevant tabs being opened?"

Chrome 58 behaves sames as FF 53 in the test cases.  But the test cases compared to our intranet are not the best.  The test http://www.omnis.com/mozilla/test.html is a lot better as the new tab/window isn't generated by a mouse click it is generated by the load of a page, which is more like our intranet.

I've just checked in-house, and apparently now Chrome is also generating the duplicate windows on the intranet.

I've just done some more testing and I think one of the original contributors used the phrase 'tab isolation' and perhaps this may have something to do with it.  If I use the system and click around, e.g. between pages (and all these pages try and kick off a new window if a message is waiting).  In my last 10 mins of testing I can't get it to kick off a duplicate.  That is until an external program, e.g. clicking a URL to the intranet site in an email triggers the browser to open a new tab.  This seems to trigger in both browsers the duplicate windows.  So my guess is that the externally generated tabs do not know about the existing window and it then generates a new one.

So... the behaviour of Firefox has clearly been changed, but is what we are now seeing deemed as the correct behaviour?  Which is breaking our intranet and the way we've used it for several years!  If it is the correct behaviour then I guess we need to look at our site in more detail to see if we can code it differently, and that may be 'in-page' alerts, rather than a new window to show them.

Thanks to all again

Gavin

Comment 21

[Nika Layzell [:nika] (ni? for response)]

(In reply to Gavin Evans from comment #20)
> Chrome 58 behaves sames as FF 53 in the test cases.  But the test cases
> compared to our intranet are not the best.  The test
> http://www.omnis.com/mozilla/test.html is a lot better as the new tab/window
> isn't generated by a mouse click it is generated by the load of a page,
> which is more like our intranet.
> 
> I've just checked in-house, and apparently now Chrome is also generating the
> duplicate windows on the intranet.

So does chrome exhibit the same behavior as Firefox now on your intranet? If it doesn't, can you explain to me what steps you take which reproduces the tab duplication in Firefox, but not in Chrome?

It would be nice if you could create a reduced test case which allows us to reliably reproduce the difference.

Comment 22

[Boris Zbarsky [:bzbarsky]]

For what it's worth, on the testcase at http://www.omnis.com/mozilla/test.html I see the following behavior in Chrome:

Chrome 58 release: cmd+click to open new tab shares name targeting.
Chrome 59 beta: cmd+click to open new tab shares name targeting.
Chrome 60 dev: cmd+click to open new tab does not seem to share name targeting.

shift+click results are the same as cmd+click.  In all cases, using "open in new tab" from context menu does _not_ seem to share name targeting.  So does any other method of opening that URL (copy/paste, open from external program, etc).

So at first glance Chrome has a thing where shift/cmd/ctrl+click (but no other method of opening things in new tabs/windows) shares name targeting stuff, but it's either not there in Chrome 60 or not there on the dev channel or something...

Comment 23

[Rick Byers]

Filed https://bugs.chromium.org/p/chromium/issues/detail?id=718204 to get to the bottom of where the change in Chrome 60 came from (and ensure there's an intentional decision here).

Comment 24

[Rick Byers]

Looks like aligning with Firefox was intentional here: https://bugs.chromium.org/p/chromium/issues/detail?id=658386

Comment 25

[Gavin Evans]

(In reply to Michael Layzell [:mystor] from comment #21)
> (In reply to Gavin Evans from comment #20)
> > Chrome 58 behaves sames as FF 53 in the test cases.  But the test cases
> > compared to our intranet are not the best.  The test
> > http://www.omnis.com/mozilla/test.html is a lot better as the new tab/window
> > isn't generated by a mouse click it is generated by the load of a page,
> > which is more like our intranet.
> > 
> > I've just checked in-house, and apparently now Chrome is also generating the
> > duplicate windows on the intranet.
> 
> So does chrome exhibit the same behavior as Firefox now on your intranet? If
> it doesn't, can you explain to me what steps you take which reproduces the
> tab duplication in Firefox, but not in Chrome?
> 
> It would be nice if you could create a reduced test case which allows us to
> reliably reproduce the difference.

Chrome and Firefox now behave the same on the intranet.  They didn't when we first started troubleshooting a few months ago, but now do.

Comment 26

[Boris Zbarsky [:bzbarsky]]

OK, so per various email threads:

1)  Safari seems to have the same behavior as current Firefox at first glance, but hard
    to say what happens once you have lots of tabs.
2)  Chrome's behavior is "yeah, it totally depends on which process things
    end up in, and hence how many tabs you already have open", but they did 
    use to put ctrl+click stuff always in the same process and stopped doing
    that in 60.  Chrome is trying to move closer to our model, not just
    process-wide targeting.
3)  It's not clear what Edge does; the Chrome folks and I got different results testing it.
    But if it similarly does the "depends on which process things are in", it might depend
    on its process allocation policy and hence number of cores or something.

Given that, we should probably just leave our behavior as-is.  For the vast majority of users of ctrl+click it's a much better behavior to put the new tab in a separate tabgroup and/or process.

Comment 27

[Nika Layzell [:nika] (ni? for response)]

(In reply to Boris Zbarsky [:bz] (still a bit busy) (if a patch has no decent message, automatic r-) from comment #26)
> Given that, we should probably just leave our behavior as-is.  For the vast
> majority of users of ctrl+click it's a much better behavior to put the new
> tab in a separate tabgroup and/or process.

I agree with this analysis. I'm inclined to leave this bug as wontfix. Once we've clarified the behavior in the spec, we can come back and make sure we're following that behavior in a separate bug.

Comment 28

[Vlad Bacia-Mociran [:VladB]]

Removing NI flag, as per :mystor update and the comments that follow.