Create DocumentChannel directly in the parent process for that initiate there
Categories
(Core :: Networking, task, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox77 | --- | fixed |
People
(Reporter: mattwoodrow, Assigned: mattwoodrow)
References
(Blocks 3 open bugs)
Details
(Whiteboard: [necko-triaged])
Attachments
(20 files, 3 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 want to be able to create the parent-side of DocumentChannel (DocumentLoadListener) directly in the parent process when we initiate a load from there, and only connect to a content process once we've received a response.
We don't want to initiate front-end loads in the old content process, since this leaks the new URI to a potentially cross-origin content process.
We also don't want to perform a process switch before initiating the load in that process since redirects might mean this switch was to the wrong process. This is also broken if the new load is handled as a download, since we need to retain the old content in that case.
Bug 1601779 is proposing to switch our current behaviour from the second to the first (getting correct behaviour, but adding a low-impact data leak). This bug tracks doing the work for the best fix.
We also want this behaviour for session history, where the state will live in the parent, and we want to initiate loads to a node in the tree without notifying the wrong content process.
Updated•5 years ago
|
Updated•5 years ago
|
Assignee | ||
Comment 2•5 years ago
|
||
We need a few things for this:
We need all the parameters that the content process would normally pass up to the parent for a URL load. I started writing a list of those, and how we could get most of them - https://docs.google.com/document/d/1u5GVULrkG0NDoiSi5mDGop6yIBCbmeEuO6VGN3_5s58
We need to synthesize any nsIWebProgressListener notifications that would normally come from the docshell and forwarded to the parent.
We also likely want to ensure that we pre-load a content process so that it can be ready at the same time as the load starts returning data.
Assignee | ||
Comment 3•5 years ago
|
||
Updated•5 years ago
|
Assignee | ||
Comment 4•5 years ago
|
||
Same process origin changes are handled by the docshell, which detects this during AsyncOnChannelRedirect and clears the mixed content permission.
Process switches load in a fresh docshell, so we need to make sure we appropriately set or clear the mixed content permission.
Depends on D67094
Assignee | ||
Comment 5•5 years ago
|
||
Depends on D67095
Assignee | ||
Comment 6•5 years ago
|
||
This was previously true, since we only used ResumeRedirectedLoad with a brand new docshell. This bug adds code for using it with existing docshells, which can have any Document (and associated timing object) loaded in them.
Depends on D67096
Assignee | ||
Comment 7•5 years ago
|
||
Depends on D67097
Assignee | ||
Comment 8•5 years ago
|
||
r.js
Depends on D67098
Assignee | ||
Comment 9•5 years ago
|
||
When we initiate URL bar loads from the parent, loads that are handled externally won't fire a load event from the content process docshell, so we should use the progress listener instead.
Depends on D67099
Assignee | ||
Comment 10•5 years ago
|
||
Depends on D67100
Assignee | ||
Comment 11•5 years ago
|
||
Depends on D70618
Assignee | ||
Comment 12•5 years ago
|
||
Depends on D70620
Assignee | ||
Comment 13•5 years ago
|
||
Depends on D70621
Assignee | ||
Comment 14•5 years ago
|
||
Depends on D70622
Assignee | ||
Comment 15•5 years ago
|
||
Depends on D70623
Assignee | ||
Comment 16•5 years ago
|
||
Depends on D70624
Assignee | ||
Comment 17•5 years ago
|
||
Depends on D70625
Assignee | ||
Comment 18•5 years ago
|
||
Depends on D70626
Assignee | ||
Comment 19•5 years ago
|
||
Depends on D70627
Assignee | ||
Comment 20•5 years ago
|
||
Depends on D70629
Assignee | ||
Comment 21•5 years ago
|
||
Depends on D71135
Comment 22•5 years ago
|
||
Comment 23•5 years ago
•
|
||
Backed out 19 changesets (Bug 1602318) for causing multiple failures
Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception&revision=4b3345b2e33b0e3927534f5c857b0c3086ed731b&selectedJob=298532363
Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=298532363&repo=autoland&lineNumber=2440
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=298532440&repo=autoland&lineNumber=20328
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=298541592&repo=autoland&lineNumber=3971
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=298532675&repo=autoland&lineNumber=43824
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=298532669&repo=autoland&lineNumber=15075
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=298544949&repo=autoland&lineNumber=1700
Backout: https://hg.mozilla.org/integration/autoland/rev/61a2d0d369c8d01189408383cc8f9477732a3354
Assignee | ||
Comment 24•5 years ago
|
||
Depends on D71135
Assignee | ||
Comment 25•5 years ago
|
||
Depends on D72110
Updated•5 years ago
|
Assignee | ||
Comment 26•5 years ago
|
||
Depends on D72111
Updated•5 years ago
|
Updated•5 years ago
|
Assignee | ||
Comment 27•5 years ago
|
||
Depends on D71136
Comment 28•5 years ago
|
||
Comment 29•5 years ago
|
||
Comment 30•5 years ago
|
||
Comment 31•5 years ago
|
||
Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception&revision=0e0bdebf223bc33c71c83ed0321c66c12fd367fb&selectedJob=299184777
Failure log: https://treeherder.mozilla.org/logviewer.html#?job_id=299184777&repo=autoland
https://treeherder.mozilla.org/logviewer.html#?job_id=299184775&repo=autoland
https://treeherder.mozilla.org/logviewer.html#?job_id=299184976&repo=autoland
Backout link: https://hg.mozilla.org/integration/autoland/rev/ab38fb8e945d
Comment 32•5 years ago
|
||
Comment 33•5 years ago
|
||
Comment 34•5 years ago
|
||
Backed out changeset d61dbc091c36 (Bug 1602318) for geckoview failures.
https://hg.mozilla.org/integration/autoland/rev/21659f178a1285e10dec0579230e52eac00d05ae
Failure log:
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=299448580&repo=autoland&lineNumber=6935
Comment 35•5 years ago
|
||
There are also bc asan perma failures like:
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=299448604&repo=autoland&lineNumber=2996
Comment 36•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/0b56956c6242
https://hg.mozilla.org/mozilla-central/rev/f64350664fbf
https://hg.mozilla.org/mozilla-central/rev/faa49f460dd5
https://hg.mozilla.org/mozilla-central/rev/ebba2085a6b5
https://hg.mozilla.org/mozilla-central/rev/e571f05c40db
https://hg.mozilla.org/mozilla-central/rev/d4dd2b03884d
https://hg.mozilla.org/mozilla-central/rev/7e2902385a6e
https://hg.mozilla.org/mozilla-central/rev/bd6752b9c333
https://hg.mozilla.org/mozilla-central/rev/54aff65a2d4f
https://hg.mozilla.org/mozilla-central/rev/18451f8ef984
https://hg.mozilla.org/mozilla-central/rev/bf51916fa039
https://hg.mozilla.org/mozilla-central/rev/34931634acb7
https://hg.mozilla.org/mozilla-central/rev/ab3a2afede33
https://hg.mozilla.org/mozilla-central/rev/77aaa5f1a81b
https://hg.mozilla.org/mozilla-central/rev/cc172a5fcbc9
https://hg.mozilla.org/mozilla-central/rev/cf6bf750f7aa
https://hg.mozilla.org/mozilla-central/rev/6d02fda2ffc5
https://hg.mozilla.org/mozilla-central/rev/beabc71edde2
https://hg.mozilla.org/mozilla-central/rev/eda5ef391b25
Assignee | ||
Comment 37•5 years ago
|
||
The pref flip patch got backed out, so reopening until that sticks.
Updated•5 years ago
|
Comment 38•5 years ago
|
||
Comment 39•5 years ago
|
||
bugherder |
Comment 40•5 years ago
•
|
||
== Change summary for alert #25779 (as of Wed, 29 Apr 2020 18:34:13 GMT) ==
Regressions:
44% raptor-tp6-twitch-firefox-cold fcp linux64-shippable-qr opt 68.33 -> 98.58
36% raptor-tp6-twitch-firefox-cold fcp linux64-shippable-qr opt 72.88 -> 98.75
Improvements:
7% raptor-tp6-instagram-firefox-cold fcp linux64-shippable opt 205.67 -> 192.25
6% raptor-tp6-outlook-firefox-cold fcp linux64-shippable opt 216.33 -> 202.92
6% raptor-tp6-bing-firefox-cold fcp windows10-64-shippable-qr opt 245.58 -> 231.08
6% raptor-tp6-outlook-firefox-cold fcp linux64-shippable opt 215.88 -> 203.25
5% raptor-tp6-reddit-firefox-cold fcp linux64-shippable opt 270.50 -> 255.75
5% raptor-tp6-instagram-firefox-cold fcp windows10-64-shippable-qr opt 205.00 -> 193.92
5% raptor-tp6-outlook-firefox-cold linux64-shippable opt 289.72 -> 274.66
5% raptor-tp6-bing-firefox-cold fcp linux64-shippable opt 248.42 -> 235.92
5% raptor-tp6-bing-firefox-cold linux64-shippable opt 252.92 -> 240.51
5% raptor-tp6-yahoo-mail-firefox-cold fcp linux64-shippable opt 282.67 -> 269.25
4% raptor-tp6-instagram-firefox-cold linux64-shippable opt 387.82 -> 370.73
4% raptor-tp6-instagram-firefox-cold fcp windows10-64-shippable opt 202.62 -> 194.08
4% raptor-tp6-bing-firefox-cold windows10-64-shippable-qr opt 237.41 -> 227.86
4% raptor-tp6-google-firefox-cold fcp linux64-shippable opt 308.96 -> 296.58
4% raptor-tp6-outlook-firefox-cold linux64-shippable-qr opt 287.59 -> 276.68
4% raptor-tp6-instagram-firefox-cold windows10-64-shippable-qr opt 375.85 -> 362.63
4% raptor-tp6-bing-firefox-cold linux64-shippable-qr opt 255.09 -> 246.18
3% raptor-tp6-reddit-firefox-cold linux64-shippable opt 732.97 -> 708.02
3% raptor-tp6-yahoo-mail-firefox-cold linux64-shippable opt 499.44 -> 482.60
3% raptor-tp6-google-firefox-cold linux64-shippable opt 411.53 -> 397.99
3% raptor-tp6-bing-firefox-cold fcp linux64-shippable-qr opt 261.42 -> 253.33
3% raptor-tp6-yandex-firefox-cold fcp linux64-shippable-qr opt 313.42 -> 304.58
3% raptor-tp6-yahoo-mail-firefox-cold linux64-shippable-qr opt 513.37 -> 500.41
2% raptor-tp6-amazon-firefox-mitm5-cold linux64-shippable opt 818.35 -> 798.34
2% raptor-tp6-bing-firefox-cold loadtime windows10-64-shippable-qr opt 315.29 -> 307.75
2% raptor-tp6-office-firefox-cold fcp windows10-64-shippable-qr opt 400.17 -> 391.50
2% raptor-tp6-office-firefox-cold windows10-64-shippable-qr opt 383.06 -> 374.91
2% raptor-tp6-youtube-firefox-cold linux64-shippable-qr opt 780.02 -> 763.68
2% raptor-tp6-yahoo-mail-firefox-cold fcp windows10-64-shippable-qr opt 320.25 -> 313.75
For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=25779
Comment 41•5 years ago
|
||
Hey Matt, there are lots of improvements from your patch but we also have two regressions for raptor-tp6-twitch.
Are these expected ?
Thanks!
Comment 42•5 years ago
|
||
I'm not sure I entirely believe the twitch regression. That test has been extremely volatile, and I suspect in this case we're just seeing a slight timing improvement knock it from one mode to another. Especially given that the last significant improvement seemed to come from a test-only change that seemed to affect a lot of raptor tests in unexpected ways.
Assignee | ||
Comment 43•5 years ago
|
||
Yeah, given that it seems to be the exact reverse of an unexplained improvement from a few days ago, then I don't think the regression is super meaningful.
Assignee | ||
Comment 44•5 years ago
|
||
I took a local profile of the twitch regression to try to understand it: https://bit.ly/3d1H4uI (sorry, xul symbolication didn't seem to work).
Looking at that it appears that the main document load of twitch returns, but we spend ~33ms waiting for the main-thread to become free, so that we can send it to the content process (which is roughly similar to the magnitude of the regression).
The main thread is busy in NeckoParent::RecvGetExtensionStream, and then we run a layout/paint cycle for the parent process content.
Looking at other profiles, it appears that have this same work on all pages, but twitch has an http response time of ~50ms, which is really quick and leads to it being ready before the other work completes. My local run of instagram had a response time of 180ms, so the main-thread was idle by the time we needed it.
I think this explains the regression, and why it comes and goes, since it wouldn't take much for the scheduling to work out better.
The extension work appears to be handling calls from raptor's 'postToControlServer' (I suspect the one inside updateTab, followed by the "status" message in nextCycle, but hard to be sure).
Henrik, is this something you've looked at?
I suspect reducing (or delaying) the number of postToControlServer calls during the time we're measuring might lead to better and more consistent results.
Comment 45•5 years ago
|
||
== Change summary for alert #25832 (as of Mon, 04 May 2020 07:14:14 GMT) ==
Improvements:
6% tabpaint linux64-shippable opt e10s stylo 53.41 -> 49.95
6% tabpaint linux64-shippable opt e10s stylo 53.42 -> 50.02
4% tsvg_static linux64-shippable opt e10s stylo 45.58 -> 43.81
3% tsvg_static linux64-shippable-qr opt e10s stylo 43.59 -> 42.20
For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=25832
Comment 46•5 years ago
|
||
(In reply to Matt Woodrow (:mattwoodrow) from comment #44)
Henrik, is this something you've looked at?
I suspect reducing (or delaying) the number of postToControlServer calls during the time we're measuring might lead to better and more consistent results.
Thanks Matt! This is very useful information and hopefully helps us to get the performance regression on bug 1627621 investigated/solved. See that bug for further updates.
Comment 47•5 years ago
|
||
(In reply to Matt Woodrow (:mattwoodrow) from comment #44)
I took a local profile of the twitch regression to try to understand it: https://bit.ly/3d1H4uI (sorry, xul symbolication didn't seem to work).
(This was probably due to bug 1635139.)
Description
•