Inconsistent results with named windows when dom.ipc.processCount>1




3 years ago
3 years ago


(Reporter: haik, Unassigned)


51 Branch

Firefox Tracking Flags

(Not tracked)


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


(1 attachment)



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

It seems as if later calls to (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 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
3) Open a new window and load namedwindows.html.
4) Click the second link to open a popup with
   Sometimes step 4 results in a new window with
   and sometimes the original window is re-used
   and loads The inconsistency is the bug.
5) Repeat steps 3 and 4 (opening more and more windows) until
   the problem occurs.


3 years ago
Whiteboard: [e10s-multi?]


3 years ago
Whiteboard: [e10s-multi?] → [e10s-multi:?]
ni?me to see what the spec says.
Flags: needinfo?(mrbkap)
Whiteboard: [e10s-multi:?] → [e10s-multi:M2]
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 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.

Flags: needinfo?(mrbkap)
I think here [1] annevk was proposing using [2] as the "related enough" test, which seems to make sense.


Comment 4

3 years ago
Yeah, the basic idea is that two top-level tabs cannot 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.
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.