Have ADocumentChannelBridge <-> DocumentLoadListener communicate via MozPromise
Categories
(Core :: Networking, enhancement, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox79 | --- | fixed |
People
(Reporter: jya, Assigned: jya)
References
Details
(Whiteboard: [necko-triaged])
Attachments
(7 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 |
This is a change we discussed with :mattwoodrow today and will play very nicely in simplifying the communication between a DocumentChannel and a DocumentLoadListener.
Right now, we have a cycle between the DocumentChannel (DC) and a DocumentLoadListener (DLL) ; the DC sends info to the DLL such as when to start (via Open) ; when to finish or disconnect.
The DLL on the other hand, needs to also know when to disconnect, and when the redirection has been completed.
The cycle in place between the two has created a fair amount of complexity, some UAF error ; and we have issues where the DC would resolve the RedirectToRealChannel promise , and then disconnect the DLL ; but due to MozPromise implementation the task telling about the resolution gets run after the DLL has actually been disconnected.
So the idea is for the DocumentChannel to call DLL::Open which would return a promise ; this promise would be resolved/rejected once the DLL is done or when it needs for the redirect to the real channel started.
The DLL would no longer hold a reference to the ADocumentChannelBridge ; removing the cycle and simplifying on what to do when we're done or there's an error.
Updated•5 years ago
|
Assignee | ||
Comment 1•5 years ago
|
||
When chaining a MozPromise set to be dispatched via the direct task queue (or synchronous), it makes sense for the chained promise to be dispatched in the same fashion.
All MozPromises generated by the IPC bindings are set to use the direct task queue in order to prevent the then runnable to run out of order with other IPC tasks.
We want to preserve that task ordering by default.
Assignee | ||
Comment 2•5 years ago
|
||
Depends on D78178
Assignee | ||
Comment 3•5 years ago
|
||
Depends on D78179
Assignee | ||
Comment 4•5 years ago
|
||
The allows to not have to deal with MozPromise::Private directly.
Assignee | ||
Comment 5•5 years ago
|
||
We would have ended up attempting to tell the child that it just died.
Assignee | ||
Comment 6•5 years ago
|
||
The earlier changes make this unnecessary. The load will start and will automatically resume once the PDocumentChannelParent::RedirectToRealChannel promise gets resolved when a DocumentChannel claim the DocumentLoadListener.
Assignee | ||
Comment 7•5 years ago
|
||
We attempt to reduce the number of event loop iterations, which would bring us back to a similar behaviour to the pre-DocumentChannel days.
This prevent some tests to have increase intermittent failures.
While ideally, we would prefer to fix or re-write those tests properly, the extra work would block us for too long.
All those increased intermittents already have bug logged about them; so we aren't hiding dust under the rust.
Depends on D78488
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Comment 9•5 years ago
|
||
Backed out for perma failures.
Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=305605580&repo=autoland&lineNumber=1415
Backout: https://hg.mozilla.org/integration/autoland/rev/0f4b97c32ba05a9e4285a2c32add44305c2aa727
Comment 10•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/0296d0f6c1d1
https://hg.mozilla.org/mozilla-central/rev/28bca5c5b8b4
https://hg.mozilla.org/mozilla-central/rev/94d47578009c
https://hg.mozilla.org/mozilla-central/rev/e3bf9a45db6a
https://hg.mozilla.org/mozilla-central/rev/abd9cd77f3cb
https://hg.mozilla.org/mozilla-central/rev/32fba417ebd0
https://hg.mozilla.org/mozilla-central/rev/7f7b98339065
Assignee | ||
Comment 11•5 years ago
|
||
so we are now blocked on bug 1644009, which will remove the dependency on AbstractThread to use direct task dispatching.
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Comment 12•4 years ago
|
||
Comment 13•4 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/02f45f660107
https://hg.mozilla.org/mozilla-central/rev/81ddcb21f057
https://hg.mozilla.org/mozilla-central/rev/f1364c78caa7
https://hg.mozilla.org/mozilla-central/rev/f6c685e4b841
https://hg.mozilla.org/mozilla-central/rev/3998aeb0935c
https://hg.mozilla.org/mozilla-central/rev/bcbaea8b572e
https://hg.mozilla.org/mozilla-central/rev/3922996e51fa
Description
•