Closed Bug 1051969 Opened 10 years ago Closed 8 years ago

window.open / link target="_blank" don't work with dom.ipc.processCount > 1

Categories

(Core :: DOM: Content Processes, defect, P2)

defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
e10s + ---

People

(Reporter: ted, Unassigned)

References

()

Details

Crash Data

Loading the URL in the URL field then clicking any of the images results in an instant content process crash for me. It looks like it's trying to do a window.open. I get an empty tab, and the original tab has crashed. (I have dom.ipc.processCount set to 10, I'm not sure if that's a factor.)
Can you reset dom.ipc.processCount to default to see if that changes the behaviour?
Flags: needinfo?(ted)
That appears to be the culprit. Bummer.
Flags: needinfo?(ted)
Summary: Crash clicking link that opens a new window → Crash clicking link that opens a new window (with dom.ipc.processCount > 1)
FWIW, this no longer crashes as of the 2014-09-04 nightly. It opens a new blank tab and then loads the URL in the original tab.

data:text/html,<a href="" onclick="window.open('http://google.com/','_blank');return false;">click</a>
Part of the problem here is that nsDocShell::SetOpener is never called on the opened tab, so openingTab is null in nsFrameLoader::TryRemoteBrowser [1]. This breaks ContentParent::GetNewOrUsedBrowserProcess's attempts to re-use the same process [2]. This doesn't seem quite right either, though, as we're not tracking if window.open() or some other API that gives handles to other contentWindows back to JS was in use.

[1] http://dxr.mozilla.org/mozilla-central/source/content/base/src/nsFrameLoader.cpp#1979

[2] http://dxr.mozilla.org/mozilla-central/source/dom/ipc/ContentParent.cpp#776
> This doesn't seem quite right either, though, as we're not tracking if window.open()
> or some other API that gives handles to other contentWindows back to JS was in use.

And indeed, this bug also affects target="_blank" links.
This smacks of the work I did in bug 989501 with smaug...
This doesn't crash anymore.
Summary: Crash clicking link that opens a new window (with dom.ipc.processCount > 1) → window.open / link target="_blank" don't work with dom.ipc.processCount > 1
Note that control-clicking something with a click->window.open handler still works properly, but it's not clear if it's properly assigning it to the same parent process.
My test ( https://bug1075316.bugzilla.mozilla.org/attachment.cgi?id=8497946 ) shows that control-clicking a button with a click->window.open handler still works improperly and may crash the old tab.

Although middle-clicking a link without handler do work fine.
OS: Windows 7 → All
Hardware: x86 → All
Priority: -- → P2
(In reply to SUN Haitao from comment #11)
> My test ( https://bug1075316.bugzilla.mozilla.org/attachment.cgi?id=8497946
> ) shows that control-clicking a button with a click->window.open handler
> still works improperly and may crash the old tab.
> 
> Although middle-clicking a link without handler do work fine.

This testcase appears to work OK AFAICT with dom.ipc.processCount currently set to 8. I also can't reproduce any crashing. Are we good to close this out as WFM?
Flags: needinfo?(sunhaitao)
I set 'dom.ipc.processCount' to 31 on my main profile for several months. I believe at least the Linux edition works normal enough. 

But it seems that the "view source" function will always show a blank tab while 'dom.ipc.processCount' > 1. Maybe there should be a follow-up for this?
Flags: needinfo?(sunhaitao)
(In reply to SUN Haitao from comment #13)
> But it seems that the "view source" function will always show a blank tab
> while 'dom.ipc.processCount' > 1. Maybe there should be a follow-up for this?

Yes, there is bug 1165309 for issues with view source when dom.ipc.processCount > 1.
(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #14)
> Yes, there is bug 1165309 for issues with view source when
> dom.ipc.processCount > 1.

In that case, let's close this one.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.