Closed Bug 1399574 Opened 7 years ago Closed 4 years ago

[e10s] Page become blank when drag and drop a zip file on the page

Categories

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

55 Branch
defect

Tracking

()

RESOLVED FIXED
mozilla78
Tracking Status
firefox-esr52 --- unaffected
firefox-esr68 --- wontfix
firefox55 --- wontfix
firefox56 --- wontfix
firefox57 --- wontfix
firefox76 --- wontfix
firefox77 --- wontfix
firefox78 --- fixed

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.
This is regressed by: Bug 1147911 in nightly. and Bug 1321430 in release.
Blocks: 1147911, 1321430
Bob, any chance you could take a look?
Flags: needinfo?(bobowencode)
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
Flags: needinfo?(bobowencode)
OS: Windows 10 → All
Hardware: Unspecified → All
Component: Tabbed Browser → Security: Process Sandboxing
Product: Firefox → Core
Component: Security: Process Sandboxing → DOM: Content Processes
Keywords: polish
Priority: -- → P3
No longer blocks: 1147911, 1321430
Depends on: 1601779
Regressed by: 1147911, 1321430
Assignee: nobody → VYV03354
Status: NEW → ASSIGNED

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?

Flags: needinfo?(VYV03354)

I believe so, due to fission support. The reviewer will confirm.

Depends on: 1594166
Flags: needinfo?(VYV03354)

(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.

Depends on: 1597154
Attachment #9120079 - Attachment is obsolete: true

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.

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.

Depends on: 1607984

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.

Flags: needinfo?(matt.woodrow)
Attachment #9120079 - Attachment is obsolete: false

Paul, can we change the whitelist sooner rather than later?

Flags: needinfo?(matt.woodrow) → needinfo?(pbone)

That's my highest priority, I'm still having some test case failures with about:newtab.

Flags: needinfo?(pbone)

emk, This should now be ready for you to continue. Sorry for the delay.

Flags: needinfo?(VYV03354)

Thank you. Bug 1597154 subsumes this patch.
Leaving open for a remaining issue (bug 1607984).

Flags: needinfo?(VYV03354)
Attachment #9120079 - Attachment is obsolete: true

(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?

Flags: needinfo?(matt.woodrow)

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.

Flags: needinfo?(matt.woodrow) → needinfo?(jyavenard)
Depends on: 1637869
Flags: needinfo?(jyavenard)

Fixed by bug 1637869.

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla78
QA Whiteboard: [qa-78b-p2]
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: