Closed Bug 1600211 Opened 4 years ago Closed 4 years ago

Handle multipart/x-mixed-replace responses in the parent process

Categories

(Core :: Networking, task, P2)

task

Tracking

()

RESOLVED FIXED
mozilla73
Tracking Status
firefox73 --- fixed

People

(Reporter: mattwoodrow, Assigned: mattwoodrow)

References

Details

(Whiteboard: [necko-triaged])

Attachments

(9 files)

47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review
47 bytes, text/x-phabricator-request
Details | Review

We currently do multipart/x-mixed-replace handling in the content process, which makes it impossible to handle downloadable parts entirely in the parent process (as we'd like to do in bug 1574372).

If we run this in the parent process, we can make a per-part decision on where the direct the content to, and only send content to be displayed down into the content process.

This also removes OnStartRequestSent from PHttpBackgroundChannel, since there should never be any messages sent earlier on this channel, so we can just assume the waiting state initially.

Depends on D55218

We can't always know when sending a part if it'll be the last one (either because the channel is later cancelled, or because the response just sends the end boundary without warning). This was initially reported in bug 339610.

Depends on D55219

We normally get HttpChannelParent::OnStartRequest directly from nsHttpChannel::OnStartRequest, where we disable content conversion and ask the child to do it instead.

When we install a multipart converter, we defer calling HttpChannelParent::OnStartRequest until we've decoded parts, at which point content conversion is already applied to the stream.

This detects that case, and stops the child trying to do it a second time (which fails, and breaks the content).

Depends on D55221

Whiteboard: [necko-triaged]
Pushed by mwoodrow@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/9300f56262d4
Convert DocumentLoadListener to use a Variant for recording and replaying nsIStreamListener functions. r=mayhemer
https://hg.mozilla.org/integration/autoland/rev/5caa332c7edb
Create a multi-part converter in nsHttpChannel if needed. r=dragana
https://hg.mozilla.org/integration/autoland/rev/e07c2e552828
Support passsing nsIMultiPartChannel values through PHttpChannel, and conditionally expose this interface on HttpChannelChild. r=mayhemer
https://hg.mozilla.org/integration/autoland/rev/1f8f8d00df76
Disable some interfaces on HttpChannelChild when we're in multipart mode since nsPartChannel didn't implement these and we don't want to support them. r=mayhemer
https://hg.mozilla.org/integration/autoland/rev/a2ec935602ab
Send OnDataAvailable and OnStopRequest on the main-thread channel when in multi-part mode to avoid complicated races across the two channels. r=mayhemer
https://hg.mozilla.org/integration/autoland/rev/5b4c042c0d18
Add nsIMultiPartChannelListener as a reliable way to detect when a multi-part channel is finished and we can break reference cycles. r=mayhemer
https://hg.mozilla.org/integration/autoland/rev/2d16a3cedb87
Support multipart channels in DocumentLoadListener. r=mayhemer
https://hg.mozilla.org/integration/autoland/rev/e4dea7d4d633
Disable content conversion by HttpChannelChild if we have already applied it by the time we get to HttpChannelParent::OnStartRequest. r=mayhemer
https://hg.mozilla.org/integration/autoland/rev/1e479194244a
Forward AllPartsStopped to HttpChannelChild to ensure that we notify the listeners correctly. r=mayhemer
Regressions: 1601243
Regressions: 1601252
Regressions: 1611081
Regressions: 1612992
Regressions: 1638422
See Also: → 1784025
You need to log in before you can comment on or make changes to this bug.