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.
Whiteboard: [e10s-multi?] → [e10s-multi:?]
ni?me to see what the spec says.
Whiteboard: [e10s-multi:?] → [e10s-multi:M2]
The relevant part of the spec appears to be . It seems to basically let us do whatever we want. In particular, it says that given two browsing contexts that are familiar  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.  https://html.spec.whatwg.org/multipage/browsers.html#the-rules-for-choosing-a-browsing-context-given-a-browsing-context-name  https://html.spec.whatwg.org/multipage/browsers.html#familiar-with
I think here  annevk was proposing using  as the "related enough" test, which seems to make sense.  https://github.com/whatwg/html/issues/1440  https://html.spec.whatwg.org/multipage/browsers.html#unit-of-related-browsing-contexts
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.
mystor is working on this right now, basically doing what comment 2 says.
Whiteboard: [e10s-multi:M2] → [e10s-multi:M2] DUPEME
This is being fixed in bug 1303196, as part of the process of consistently defining a unit of related browsing contexts.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1303196
You need to log in before you can comment on or make changes to this bug.