1359021 - [e10s] Named popup window is opened in duplicate when open it from file: protocol

Status: VERIFIED FIXED

(Core :: DOM: Navigation, defect)

Description

[Alice0775 White]

Attachment: sample html

[Tracking Requested - why for this release]:

Reproducible: always

Steps to reproduce:
1. Make sure e10s enabled
2. Open window.open("url", "named", "options")
   e.g., window.open("http://example.com", "named", "width=400,height=400");
3. Repeat step.2


alternative steps to reproduce:
1. Make sure e10s enabled
2. Open attached html
3. Click [open popup]
4. Repeat step.3

Actual Results:
Popup windows are opened in duplicate

Expected Results:
Pop-up windows should be reused if same target name.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

Is this a recent regression, or e10s regression?

Comment 2

[Alice0775 White]

(In reply to Olli Pettay [:smaug] from comment #1)
> Is this a recent regression, or e10s regression?

[Reproduce]
Nightly55.0a1 with e10s

[Not reproduce]
Nightly55.0a1 without e10s
54.0b1 with e10s
54.0b1 without e10s
53.0 with e10s
53.0 without e10s


This problem is only occurred on nightly channel, not on aurora/beta/release channel.
And this problem is not a recent regression.

Comment 3

[Alice0775 White]

It only happens when open popup from file: protocol.

alternative steps to reproduce:
0. Save attached html to local file system
1. Make sure e10s enabled
2. Open the saved html with file:// protocol
3. Click [open popup]
4. Repeat step.3


Regression Window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=49228a69b071bc200360aa43845b42b996759479&tochange=0637dd270ef14763921d3099b6f6d5780fa702f6

Regressed by: Bug 1147911

Comment 4

[Blake Kaplan (:mrbkap) (inactive)]

This is definitely a bug, the only question is about prioritization. This should only affect named links to non-file: targets (that is, `window.open("file://....", "name")` should continue to work correctly). We should be able to fix it with a map in the parent process from (ContentParent, name) -> TabParent and make ContentParent::RecvCreateWindowInDifferentProcess look in that map to find the proper tab parent to load the URI in (also making sure to update the map if the tab/window gets closed). Currently, only file URIs can end up in this state, so we don't have to worry about the namespace stuff in the HTML spec.

That being said, I don't know how common this is. Bob, any ideas?

Comment 5

[Bob Owen (:bobowen)]

(In reply to Blake Kaplan (:mrbkap) from comment #4)
> This is definitely a bug, the only question is about prioritization. This
> should only affect named links to non-file: targets (that is,
> `window.open("file://....", "name")` should continue to work correctly). We
> should be able to fix it with a map in the parent process from
> (ContentParent, name) -> TabParent and make
> ContentParent::RecvCreateWindowInDifferentProcess look in that map to find
> the proper tab parent to load the URI in (also making sure to update the map
> if the tab/window gets closed). Currently, only file URIs can end up in this
> state, so we don't have to worry about the namespace stuff in the HTML spec.
> 
> That being said, I don't know how common this is. Bob, any ideas?

Thanks Alice, for finding this.

Since bug 1351358, I've become more concerned about my decision to not load any http(etc.) at the top level in the file content process.
This just adds weight to those concerns.

It looks like the current patches I have for bug 1351358, will fix this.
My plan is to load linked/related web pages in the file content process even at the top level.
As soon as you navigate away from the same origin via the url bar (or some other means not directly linked/opened from the content) then we will switch to a normal web content process.

This is similar to how Chrome handles this situation, although they allow coming back using history.
In our case the relationship is permanently lost, which is an existing issue on process switch if you navigate to a parent loaded page in release currently.
This feels like a fairly minor edge case to me.

Comment 6

[Julien Cristau [:jcristau]]

Tracking for 55 since the separate file:// process is scheduled to ship there, AFAIK.

Comment 7

[Bob Owen (:bobowen)]

Fixed as part of bug 1351358.

Comment 8

[Simona Badau, Desktop QA]

Reproduced the initial issue using Nightly 55.0a1 (Build ID: 20170510030301) on Windows 10 x64.

Verified as fixed using the latest Nightly 55.0a1 (Build ID: 20170523030206) on Windows 10 x64, Ubuntu 16.04 x64 and Mac OS X 10.12.