1348018 - Toplevel POST document loads may lose data if E10SUtils.shouldLoadURIInThisProcess(aURI) returns false

Status: NEW

(Core :: DOM: Navigation, defect, P2)

Description

[Nika Layzell [:nika] (ooo, ni? for response)]

Attachment: simple_test_case_download_and_open_as_file_uri.html

Consider: Current document is a file:// URI, and it has a form with a POST method which targets an https:// URI. With the separate file process, an attempt to submit this form will cause the data to be discarded, and the load to occur within a normal content process as a GET request.

The attached test case can be used by downloading the attached html file, and opening it as a file:// URI. In e10s-enabled nightly (which uses the separate file process), clicking the submit button will show the text NOT FOUND. In e10s-disabled nightly (which does not), clicking the submit button will show a JSON dump of the request data.

Comment 1

[Andrew Overholt [:overholt]]

Michael, are you planning on working on this? It seems pretty bad for Large-Allocation cases.

Comment 2

[Nika Layzell [:nika] (ooo, ni? for response)]

(In reply to Andrew Overholt [:overholt] from comment #1)
> Michael, are you planning on working on this? It seems pretty bad for
> Large-Allocation cases.

I've made a fix in bug 1347983 for large-allocation. This is for the rest of the cases.

It looks like bug 1344465 is going to fix it in the generic case.

Comment 3

[Andrew Overholt [:overholt]]

(In reply to Michael Layzell [:mystor] from comment #2)
> (In reply to Andrew Overholt [:overholt] from comment #1)
> > Michael, are you planning on working on this? It seems pretty bad for
> > Large-Allocation cases.
> 
> I've made a fix in bug 1347983 for large-allocation. This is for the rest of
> the cases.
> 
> It looks like bug 1344465 is going to fix it in the generic case.

Should we just mark this as a dupe of bug 1344465, then?

Comment 4

[Nika Layzell [:nika] (ooo, ni? for response)]

I don't think we should anymore. 1344465 has been stagnant for a while, and has become focused specifically on the webextension case, while this bug is more general.

I think that what might end up happening is us copying the trick we're doing for file URIs (which is cheating and just loading web content in the webextension process) before 57 (which we should probably get on - I didn't realize that this bug had stagnated, and it seems pretty bad), and then fixing the general case (this bug) later.

The patches in bug 1344465 will probably be useful for fixing this bug though.

Comment 5

[Andrew Overholt [:overholt]]

OK, I'm going to mark this as P2 so we'll see it but recognize that it won't be targeted at 57. Thanks!