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

RESOLVED DUPLICATE of bug 1303196

Status

()

Core
DOM: Content Processes
RESOLVED DUPLICATE of bug 1303196
11 months ago
10 months ago

People

(Reporter: haik, Unassigned)

Tracking

51 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [e10s-multi:M2] DUPEME)

Attachments

(1 attachment)

(Reporter)

Description

11 months ago
Created attachment 8796207 [details]
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.
(Reporter)

Updated

11 months ago
Whiteboard: [e10s-multi?]
(Reporter)

Updated

11 months ago
Whiteboard: [e10s-multi?] → [e10s-multi:?]

Comment 1

11 months ago
ni?me to see what the spec says.
Flags: needinfo?(mrbkap)
Whiteboard: [e10s-multi:?] → [e10s-multi:M2]

Comment 2

11 months ago
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
Flags: needinfo?(mrbkap)
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

11 months ago
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: 10 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1303196
You need to log in before you can comment on or make changes to this bug.