Only send resizes for remote browsers once per frame.
Categories
(Core :: Layout, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox132 | --- | fixed |
People
(Reporter: emilio, Assigned: emilio)
References
Details
Attachments
(6 files)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review |
Assignee | ||
Comment 1•1 month ago
|
||
Do it at the same time as UpdateRemoteFrameEffects() (so, intersection
observer timing). Otherwise we can see flickering sometimes from the
resize with the previous patch (and this should be less work, when we
resize).
Non-remote frames need to synchronously communicate their resizes
(because JS could access the frame), but that's not an issue for
non-remote frames.
This should also more reliably prevent issues like bug 1910887 or like
bug 1764655, and paves the way for fixing bug 1750189 (which stalled) in
a similar fashion.
I tested this in a build with a couple hundred tabs open and it doesn't
measurably show up. I think we should consider not communicating resizes
to background tabs / hidden remote iframes, at least for top levels.
Assignee | ||
Comment 2•28 days ago
|
||
See incoming patch for reasoning.
Assignee | ||
Comment 3•28 days ago
|
||
After the previous patch, we don't jank all remote tabs when resizing
the browser, so this can go. This should also make general window
resizing faster.
Assignee | ||
Comment 4•28 days ago
|
||
No behavior change, just moving code around for the following patches.
Assignee | ||
Comment 5•28 days ago
|
||
This is currently not an issue because for top levels we don't look at
the effects info. But:
-
It is useful, because it might allow to remove some special-cases
around here[1]. -
For the next patch I want to also communicate resizes, where we'll
need to handle them.
Updated•28 days ago
|
Updated•28 days ago
|
Comment 10•26 days ago
|
||
Comment 11•26 days ago
|
||
Backed out for causing wpt failures in no_window_open_when_term_nesting_level_nonzero.window.html
- Backout link
- Push with failures
- Failure Log
- Failure line: PROCESS-CRASH | MOZ_ASSERT(false) (MOZ_ASSERT_UNREACHABLE: Top level BrowserChild w/ non-top level Document?) [@ mozilla::dom::GetOopIframeMetrics] | /html/browsers/the-window-object/open-close/no_window_open_when_term_nesting_level_nonzero.window.html
TEST-UNEXPECTED-CRASH | /html/browsers/the-window-object/open-close/no_window_open_when_term_nesting_level_nonzero.window.html | expected ERROR
Comment 12•26 days ago
|
||
We also have this failure coming from this bug: https://treeherder.mozilla.org/logviewer?job_id=474367350&repo=autoland if you could take a look at it before you land the fix.
Assignee | ||
Comment 13•25 days ago
|
||
Calling setViewport on a background tab would wait forever without this
tweak after D221995, because we won't resize it until it becomes active.
Some tests like the ones mentioned in comment 12 call newPage() multiple
times at once, and newPage() calls setViewport() if there is a default
viewport set, which triggered this bug.
Make this work by reusing the AppWindow logic for sizing popup windows,
with a tweak so that we also resize background tabs.
Assignee | ||
Updated•25 days ago
|
Comment 14•25 days ago
|
||
Comment 15•25 days ago
|
||
Comment 16•25 days ago
|
||
bugherder |
Comment 17•24 days ago
|
||
Assignee | ||
Updated•24 days ago
|
Comment 18•24 days ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/1b365189821a
https://hg.mozilla.org/mozilla-central/rev/05355ea5dd7c
https://hg.mozilla.org/mozilla-central/rev/308329f23acd
Comment 20•16 days ago
|
||
(In reply to Pulsebot from comment #15)
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c3dc5d769ffe
Update remote effects on top descendants. r=mstange
https://hg.mozilla.org/integration/autoland/rev/22eeb2b5ca5b
Only send resizes for remote browsers once per frame.
r=mstange,extension-reviewers,tabbrowser-reviewers,dao,robwu
Perfherder has detected a talos performance change from push 22eeb2b5ca5b2d4a8e80ed34a1159d60f5cd594f.
Improvements:
Ratio | Test | Platform | Options | Absolute values (old vs new) |
---|---|---|---|---|
19% | tresize | linux1804-64-shippable-qr | e10s fission stylo webrender | 27.47 -> 22.33 |
18% | tresize | linux1804-64-shippable-qr | e10s fission stylo webrender | 27.98 -> 22.91 |
13% | tresize | linux1804-64-shippable-qr | e10s fission stylo webrender-sw | 28.44 -> 24.73 |
10% | tresize | macosx1015-64-shippable-qr | e10s fission stylo webrender-sw | 7.03 -> 6.34 |
3% | tresize | windows11-64-shippable-qr | e10s fission stylo webrender-sw | 5.27 -> 5.09 |
Details of the alert can be found in the alert summary, including links to graphs and comparisons for each of the affected tests.
If you need the profiling jobs you can trigger them yourself from treeherder job view or ask a sheriff to do that for you.
You can run these tests on try with ./mach try perf --alert 2175
For more information on performance sheriffing please see our FAQ.
Updated•10 days ago
|
Updated•10 days ago
|
Updated•10 days ago
|
Description
•