Split DocumentChannelParent into two classes.
Categories
(Core :: Networking, enhancement, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox72 | --- | fixed |
People
(Reporter: mattwoodrow, Assigned: mattwoodrow)
Details
(Whiteboard: [necko-triaged])
Attachments
(1 file)
Currently DocumentChannelParent serves two fairly separate functions.
-
It acts as a logic controller for a connecting load (ultimately on behalf of a CanonicalBrowsingContext), that creates a channel and once it gets a response, figures out the right thing to do with it (send to the originating process, send to a new process, handle as a download etc).
-
It's the parent-side IPDL actor for an nsIChannel implementation that we hold in the docshell as a placeholder while the above happens. This is largely a backwards compatibility hack since docshell expects to have a channel when a load has been initiated (but in the future we could do loads more directly through BrowsingContext and rewrite docshell to understand waiting on that).
We also have plans to use DocumentChannel from the chrome process (which wouldn't need an IPDL actor for the nsIChannel impl), and to allow initiating content process loads directly from the chrome process (where we wouldn't have setup the IPDL actor). In both of these cases, the latter functionality wouldn't be needed, but we currently have to have both at all times.
I'd like to split DocumentChannelParent into two distinct classes, each with a single clear purpose. I'll then try adding parent-process DocumentChannel support that doesn't use the parent-IPDL actor bit (in a separate bug).
|
Assignee | |
Comment 1•5 years ago
|
||
Currently DocumentChannelParent serves two fairly separate functions.
It acts as a logic controller for a connecting load (ultimately on behalf of a CanonicalBrowsingContext), that creates a channel and once it gets a response, figures out the right thing to do with it (send to the originating process, send to a new process, handle as a download etc).
It's the parent-side IPDL actor for an nsIChannel implementation that we hold in the docshell as a placeholder while the above happens. This is largely a backwards compatibility hack since docshell expects to have a channel when a load has been initiated (but in the future we could do loads more directly through BrowsingContext and rewrite docshell to understand waiting on that).
This patch splits this into two separate classes (and adds more documentation explaining exactly what each one does). It shouldn't affect any behaviour.
Depends on D53382
|
||
Updated•5 years ago
|
Pushed by mwoodrow@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/e76dbab2aea8 Split DocumentChannelParent into two separate classes (DocumentLoadListener and DocumentChannelParent). r=mayhemer,jya
|
||
Comment 3•5 years ago
|
||
| bugherder | ||
|
||
Updated•5 years ago
|
Description
•