Open Bug 1399574 Opened 2 years ago Updated 2 years ago

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


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

55 Branch



Tracking Status
firefox-esr52 --- unaffected
firefox55 --- wontfix
firefox56 --- wontfix
firefox57 --- wontfix


(Reporter: alice0775, Unassigned)



(Keywords: multiprocess, polish, regression)

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.

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
You need to log in before you can comment on or make changes to this bug.