Use DocumentChannel for docshells in the parent process
Categories
(Core :: Networking, task, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox77 | --- | fixed |
People
(Reporter: mattwoodrow, Assigned: jya)
References
(Blocks 2 open bugs)
Details
(Whiteboard: [necko-triaged])
Attachments
(20 files, 2 obsolete 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 | |
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 | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
47 bytes,
text/x-phabricator-request
|
Details | Review |
We currently only create a DocumentChannel for loads that initiate within a content process, but it would be nicer to always create them and unify our codepaths more.
![]() |
||
Comment 1•6 years ago
|
||
Matt, this sounds to me as a P3 only, but please feel free to raise the priority.
Reporter | ||
Comment 2•5 years ago
|
||
Try push with my work thus far on this: https://treeherder.mozilla.org/#/jobs?repo=try&revision=b4823053afbb8f77f8a11a8f8f53d00234df6471
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 3•5 years ago
|
||
This also removes the need to call SerializeRedirectData to set mRedirectChannelId to the proper value and register the channel.
Assignee | ||
Comment 4•5 years ago
|
||
Depends on D69998
Assignee | ||
Comment 5•5 years ago
|
||
If we were to open the window to close it immediately; we would leak a nsHtml5Parser object.
Depends on D69999
Assignee | ||
Comment 6•5 years ago
|
||
Depends on D70000
Assignee | ||
Comment 7•5 years ago
|
||
Regressiong from bug 1607987. This prevented from QueryInterface(Ci.nsIIdentChannel) in JS on the channel.
Depends on D70001
Assignee | ||
Comment 8•5 years ago
|
||
This gets triggered with DocumentChannel is enabled in the parent process. Not sure how it worked in the past.
Depends on D70002
Assignee | ||
Comment 9•5 years ago
|
||
Depends on D70003
Assignee | ||
Comment 10•5 years ago
|
||
The test waited one event loop before testing if the attributes could be changed.
There wasn't any guarantees that the load could have actually started by then being asynchronous in nature.
The use of DocumentChannel introduces some extra hops when starting a load, and we can not longer simply wait for one event loop.
So instead we wait for the nsIWebProgress event that notifies that the docShell has actually started the load.
Depends on D70004
Assignee | ||
Comment 11•5 years ago
|
||
The DocumentLoadListener is setting up a ParentChannelListener to go in between the normal listener->channel chain.
ParentChannelListener not implementing nsIThreadRetargetableStreamListener would prevent a nsHtml5StreamParser settings things up so that OnDataAvailable could be sent to a html parser thread off the main thread; improving performance.
Depends on D70005
Assignee | ||
Comment 12•5 years ago
|
||
The code assumed that nsJARChannel::RetargetDeliveryTo would have been called synchronously from nsJARChannel::OnStartRequest, which would be true if we weren't using a DocumentChannel.
The DocumentLoadListener queue the calls to OnStartRequest until the final redirect.
nsJARChannel::RetargetDelivery mRequest member is be set to forward the call.
So we need to only reset it once OnStopRequest has been received.
Depends on D70006
Assignee | ||
Comment 13•5 years ago
|
||
We must wait for the iframe created by extension1 to be fully loaded before we can attempt to send a message to it.
So we send a message when it is ready, and suspend the execution until this message is received.
Depends on D70007
Assignee | ||
Comment 14•5 years ago
|
||
Add ParentProcessDocumentChannel object. This object is a DocumentChannel that will start a channel load from the parent process via a DocumentChannel.
The aim of this task is two-fold.
1- Be consistent on how we handle redirects before continuing the load on the final channel.
2- Prepare to initiate a process switch when needed without having to go via an intermediary content process, saving a process switch. This task will be done in a follow-up task.
The behaviour of the ParentProcessDocumentChannel is similar in logic to the DocumentChannelChild/DocumentChannelParent pair.
The ParentProcessDocumentChannel sets up a DocumentLoadListener, have it handle the redirects and upon completion continue the load on the final channel.
Depends on D70008
Assignee | ||
Comment 15•5 years ago
|
||
Some tests rely on this event to start action. The DocumentChannel had no equivalent. We make the ParentProcessDocumentChannel listen to this event and if it matches the nsIChannel currently in use in the DocumentLoadListener than we emit a similar document-on-modify-request event on the DocumentChannel.
Depends on D70009
Assignee | ||
Comment 16•5 years ago
|
||
When starting a load via the ParentProcessDocumentChannel, the event http-on-modify-request will be fired before the DocumentLoadListener has a chance to set the notificationCallback attribute.
When using a DocumentChannel, this test will not trigger the expected codepath as the DOMWindowCreated event will be fired once the channel is fully up and running; which in effect is also a fix of the original bug 1339722
Instead we use the document-on-modify-request event when the DocumentChannel is enabled.
Depends on D70010
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Assignee | ||
Comment 17•5 years ago
|
||
addA11yLoadEvent gets the contentWindow and wait for the document from that window to fire the load event.
Enabling the DocumentChannel for parent process load (or here in non-e10s mode) we have one extra event loop before the load starts.
So the window passed to addAllyLoadEvent would have been of the about:blank page.
The current code was based on an observable behaviour which was that the load was occuring synchronously.
DocumentChannel broke that assumption.
Assignee | ||
Comment 20•5 years ago
|
||
This file will be removed in bug 1628752 anyway.
Comment 21•5 years ago
|
||
Comment 22•5 years ago
|
||
Comment 23•5 years ago
|
||
Backed out for failing test_bug1339722.html
Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&selectedJob=297693863&resultStatus=testfailed%2Cbusted%2Cexception&revision=a3a28be516f9babfe0e22906ed93f858183a8859
Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=297693863&repo=autoland&lineNumber=141671
ESlint: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=297692604&repo=autoland&lineNumber=333
Backout: https://hg.mozilla.org/integration/autoland/rev/796728edcf88e9741b803ef38da2a484daec5745
Comment 24•5 years ago
|
||
Assignee | ||
Comment 25•5 years ago
|
||
4 patches didn't get pushed for some reasons.
Comment 26•5 years ago
|
||
Backed out 15 changesets (Bug 1607984) for causing very frequent reftest faiures CLOSED TREE
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=297727197&repo=autoland&lineNumber=1505
Assignee | ||
Comment 27•5 years ago
|
||
the window may be showed before the page has loaded. In which case, setting a listener for the pageshow event would never be triggered as it would be set too late.
Assignee | ||
Comment 28•5 years ago
|
||
We disable it on Android for now due to unexplained reftest start failures.
Comment 29•5 years ago
|
||
Comment 30•5 years ago
|
||
Backed out for multiple test failures e.g test timeouts
Failure logs:
- https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=298950034&repo=autoland&lineNumber=1447
- https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=298949285&repo=autoland&lineNumber=760
- https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=298949916&repo=autoland&lineNumber=1122
Backout: https://hg.mozilla.org/integration/autoland/rev/10bf0d7468e0349634b9ba7291525318e0673402
Comment 31•5 years ago
|
||
Assignee | ||
Updated•5 years ago
|
Comment 32•5 years ago
|
||
Backed out for leaks on browser_ext_webRequest.js
backout: https://hg.mozilla.org/integration/autoland/rev/ed118e721ff6df179e51bba78c90d4e748d64013
failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=298974407&repo=autoland&lineNumber=41599
[task 2020-04-23T07:27:03.519Z] 07:27:03 INFO - GECKO(4768) | [Parent 3192, Main Thread] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005 (NS_ERROR_FAILURE): file /builds/worker/checkouts/gecko/netwerk/base/nsNetUtil.cpp, line 2323
[task 2020-04-23T07:27:03.519Z] 07:27:03 INFO - GECKO(4768) | [Parent 3192, Main Thread] WARNING: 'NS_FAILED(rv)', file /builds/worker/checkouts/gecko/caps/ContentPrincipal.cpp, line 398
[task 2020-04-23T07:27:03.519Z] 07:27:03 INFO - GECKO(4768) | [Parent 3192, Main Thread] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005 (NS_ERROR_FAILURE): file /builds/worker/checkouts/gecko/caps/ContentPrincipal.cpp, line 423
[task 2020-04-23T07:27:03.562Z] 07:27:03 INFO - GECKO(4768) | [Parent 3192, Main Thread] WARNING: Extra shutdown CC: 'i < NORMAL_SHUTDOWN_COLLECTIONS', file /builds/worker/checkouts/gecko/xpcom/base/nsCycleCollector.cpp, line 3359
[task 2020-04-23T07:27:03.817Z] 07:27:03 INFO - TEST-INFO | Main app process: exit 0
[task 2020-04-23T07:27:03.817Z] 07:27:03 INFO - TEST-INFO | Confirming we saw 2475 DOCSHELL created and 2472 destroyed log strings.
[task 2020-04-23T07:27:03.817Z] 07:27:03 INFO - TEST-INFO | Confirming we saw 6722 DOMWINDOW created and 6707 destroyed log strings.
[task 2020-04-23T07:27:03.818Z] 07:27:03 ERROR - TEST-UNEXPECTED-FAIL | browser/components/extensions/test/browser/browser_ext_webRequest.js | leaked 2 window(s) until shutdown [url = chrome://global/content/win.xhtml]
[task 2020-04-23T07:27:03.818Z] 07:27:03 ERROR - TEST-UNEXPECTED-FAIL | browser/components/extensions/test/browser/browser_ext_webRequest.js | leaked 1 window(s) until shutdown [url = chrome://browser/content/browser.xhtml]
[task 2020-04-23T07:27:03.818Z] 07:27:03 ERROR - TEST-UNEXPECTED-FAIL | browser/components/extensions/test/browser/browser_ext_webRequest.js | leaked 1 window(s) until shutdown [url = about:blank]
[task 2020-04-23T07:27:03.819Z] 07:27:03 INFO - TEST-INFO | browser/components/extensions/test/browser/browser_ext_webRequest.js | windows(s) leaked: [pid = 3192] [serial = 1178], [pid = 3192] [serial = 1179], [pid = 3192] [serial = 1182], [pid = 3192] [serial = 1185]
[task 2020-04-23T07:27:03.819Z] 07:27:03 INFO - TEST-INFO | browser/components/extensions/test/browser/browser_ext_webRequest.js | This test created 1 hidden window(s)
Assignee | ||
Comment 33•5 years ago
|
||
Can't reproduce the leak on a fresh try run based in central.
Seems to have been due to specific and local autoland issue.
Updated•5 years ago
|
Assignee | ||
Comment 34•5 years ago
|
||
Move DocumentChannelChild methods to the base class as they will be needed with the ParentProcessDocumentChannel
Depends on D70008
Assignee | ||
Comment 35•5 years ago
|
||
This prepares the code so that it doesn't always have to deal with dealing with another process as is the case when using DocumentChannelChild/DocumentChannelParent
Depends on D72271
Assignee | ||
Comment 36•5 years ago
|
||
Depends on D72272
Updated•5 years ago
|
Comment 37•5 years ago
|
||
Assignee | ||
Comment 38•5 years ago
|
||
The test became invalid with the preference introduced in P17.
Comment 39•5 years ago
|
||
Updated•5 years ago
|
Comment 40•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/87ff410d6d5d
https://hg.mozilla.org/mozilla-central/rev/e73b1ad10587
https://hg.mozilla.org/mozilla-central/rev/dac4a7633252
https://hg.mozilla.org/mozilla-central/rev/9f2a48ab3d51
https://hg.mozilla.org/mozilla-central/rev/2eaf4a867ed7
https://hg.mozilla.org/mozilla-central/rev/5883b99090e5
https://hg.mozilla.org/mozilla-central/rev/0db8c5437f96
https://hg.mozilla.org/mozilla-central/rev/4d0b7005e95e
https://hg.mozilla.org/mozilla-central/rev/4685da63cb65
https://hg.mozilla.org/mozilla-central/rev/c75b3ce009e8
https://hg.mozilla.org/mozilla-central/rev/ce44570cce1d
https://hg.mozilla.org/mozilla-central/rev/277d3fd86386
https://hg.mozilla.org/mozilla-central/rev/2896323daed4
https://hg.mozilla.org/mozilla-central/rev/e27e24312c27
https://hg.mozilla.org/mozilla-central/rev/b507b6482b9d
https://hg.mozilla.org/mozilla-central/rev/d77b869fb6b2
https://hg.mozilla.org/mozilla-central/rev/383252c721a1
https://hg.mozilla.org/mozilla-central/rev/baba9f0949b1
https://hg.mozilla.org/mozilla-central/rev/a6ae63b01821
https://hg.mozilla.org/mozilla-central/rev/598a2ed6fac1
Description
•