[e10s] Page become blank when drag and drop a zip file on the page
Categories
(Core :: DOM: Content Processes, defect, P3)
Tracking
()
People
(Reporter: alice0775, Assigned: emk)
References
(Regression)
Details
(Keywords: multiprocess, polish, regression)
Attachments
(1 obsolete file)
This is only reproduced with e10s. Reproducible: always Steps To reproduce: 1. Open web page 2. Drag a zip(7z, tar etc) file from Explorer and drop the contentarea so that download helper dialog will pop up Actual Results: Page turn to blank. The page url is still in the Location bar. The page will redraw with F5. Expected Results: Page should not be blank.
Reporter | ||
Comment 1•7 years ago
|
||
This is regressed by: Bug 1147911 in nightly. and Bug 1321430 in release.
Comment 3•7 years ago
|
||
This is a similar problem to bug 1175267, for example if I turn off the file content process (and reduce the sandbox to allow read access) and drop a zip file onto a parent rendered page (e.g. about:robots) I get the same result. It's not really just zip files either. The issue is that we switch the process (either to file content process or to web in the example above) and then that process decides it can't handle the content and throws it back up to the parent. We could special case application/x-zip-compressed mime type and possibly others like at [1], but really that seems like even more of a sticking plaster. It would seem to makes sense to have the decision making about whether a child can handle the content up front, but that seems like a fair bit of a re-design. [1] https://hg.mozilla.org/mozilla-central/file/tip/browser/base/content/browser.js#l1029
Updated•7 years ago
|
Updated•7 years ago
|
Updated•7 years ago
|
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 4•4 years ago
|
||
Updated•4 years ago
|
Comment 5•4 years ago
|
||
Attached file Bug 1399574 - Don't trigger a process switch before loading file:// URLs. r?mattwoodrow
Does this mean we will do the process switch later in the load now?
Assignee | ||
Comment 6•4 years ago
•
|
||
I believe so, due to fission support. The reviewer will confirm.
Comment 7•4 years ago
|
||
(In reply to Bob Owen (:bobowen) from comment #5)
Attached file Bug 1399574 - Don't trigger a process switch before loading file:// URLs. r?mattwoodrow
Does this mean we will do the process switch later in the load now?
Indeed we do!
We now have parent-process code that runs when we get a response from the connection (and have finished all http redirects), and makes a decision about how to handle the content (download vs document) and in which process.
This patch should be correct (disabling the preemptive process switch), but it's superseded by bug 1597154, so I'd rather wait for that to land and not bitrot Paul.
Updated•4 years ago
|
Assignee | ||
Comment 8•4 years ago
|
||
I found that this problem still happens even if bug 1597154 is fixed when I drag a zip file on some special pages such as about:robots
.
Comment 9•4 years ago
|
||
Process switching from the response only supports switching between content processes, but not into or out of the parent process.
That means we still have to trigger the preemptive process switch for loads that we think will change in that way (about:robots runs in the parent, the file:// zip content), and can have this bug.
Bug 1607984 should add support for these remaining types of switches.
Assignee | ||
Comment 10•4 years ago
•
|
||
Could you please reconsider about landing this alone? Bug 1597154 is stuck and changing the DC whitelist is going to be separated out from bug 1597154. This long-standing problem is very frustrating for me.
Updated•4 years ago
|
Comment 11•4 years ago
|
||
Paul, can we change the whitelist sooner rather than later?
Comment 12•4 years ago
|
||
That's my highest priority, I'm still having some test case failures with about:newtab.
Comment 13•4 years ago
|
||
emk, This should now be ready for you to continue. Sorry for the delay.
Assignee | ||
Comment 14•4 years ago
|
||
Thank you. Bug 1597154 subsumes this patch.
Leaving open for a remaining issue (bug 1607984).
Updated•4 years ago
|
Assignee | ||
Comment 15•4 years ago
|
||
(In reply to Matt Woodrow (:mattwoodrow) from comment #9)
Process switching from the response only supports switching between content processes, but not into or out of the parent process.
That means we still have to trigger the preemptive process switch for loads that we think will change in that way (about:robots runs in the parent, the file:// zip content), and can have this bug.
Bug 1607984 should add support for these remaining types of switches.
about:robots
still becomes blank when I dropped a zip file even after bug 1607984 is fixed. What is missing?
Comment 16•4 years ago
|
||
Process switching between pages that load in the parent (like about:robots) and content process is still using the 'old' way, which has bugs like this.
Jean-Yves is going to work on supporting chrome<->content process switches next, which should allow us to fix this.
Adding ni? just so he sees this, as a good test case to work with.
Assignee | ||
Comment 17•4 years ago
|
||
Fixed by bug 1637869.
Updated•4 years ago
|
Updated•4 years ago
|
Updated•2 years ago
|
Description
•