1306367 - Inconsistent window.open() results with named windows when dom.ipc.processCount>1

Status: RESOLVED DUPLICATE of bug 1303196

(Core :: DOM: Content Processes, defect)

Description

[Haik Aftandilian [:haik]]

Attachment: Named window test case HTML file.

With dom.ipc.processCount>1, when a named window has been created, say "mynamedwindow", later calls to window.open(URL, "mynamedwindow, flags) don't reliably result in URL loading in the existing "mynamedwindow" window.

It seems as if later calls to window.open() (from the same origin) from a different content process don't find the existing window and instead open a new window, but if the later call to window.open() is in the same content process, the existing window is used.

The behavior differs from the dom.ipc.processCount=1 case which always uses the existing window. When dom.ipc.processCount>1, the behavior is unpredictable.

It would be better if we either always opened a new window or always used the existing window.

Steps to reproduce:
1) Open attached namedwindows.html test file.
2) Click the first link to open a popup with wikipedia.org.
3) Open a new window and load namedwindows.html.
4) Click the second link to open a popup with mozilla.org.
   Sometimes step 4 results in a new window with mozilla.org
   and sometimes the original wikipedia.org window is re-used
   and loads mozilla.org. The inconsistency is the bug.
5) Repeat steps 3 and 4 (opening more and more windows) until
   the problem occurs.

Comment 1

[Blake Kaplan (:mrbkap) (inactive)]

ni?me to see what the spec says.

Comment 2

[Blake Kaplan (:mrbkap) (inactive)]

The relevant part of the spec appears to be [1]. It seems to basically let us do whatever we want. In particular, it says that given two browsing contexts that are familiar [2] with each other to allow us to link them by name if "user agent determines that the two browsing contexts are related enough that it is ok if they reach each other".

Given that, I propose that instead of having (effectively) a per-process list of names to windows, we instead maintain one for each top-level window (browsing context in spec terminology) so that multiple window.open calls from a given collection of top-level pages can refer to the same windows, but other instances of those pages *won't* share those window names.

[1] https://html.spec.whatwg.org/multipage/browsers.html#the-rules-for-choosing-a-browsing-context-given-a-browsing-context-name
[2] https://html.spec.whatwg.org/multipage/browsers.html#familiar-with

Comment 3

[Bob Owen (:bobowen)]

I think here [1] annevk was proposing using [2] as the "related enough" test, which seems to make sense.

[1] https://github.com/whatwg/html/issues/1440
[2] https://html.spec.whatwg.org/multipage/browsers.html#unit-of-related-browsing-contexts

Comment 4

[Anne (:annevk)]

Yeah, the basic idea is that two top-level example.com tabs cannot window.open() to the same tab, they'll each get their own. Other browsers already do this I believe. The less sharing the better for parallelism. Copying bz as he's been somewhat involved in these conversations, despite really working on something else.

Comment 5

[Boris Zbarsky [:bzbarsky]]

mystor is working on this right now, basically doing what comment 2 says.

Comment 6

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

This is being fixed in bug 1303196, as part of the process of consistently defining a unit of related browsing contexts.