200ms long white frame during navigation on amazon music
Categories
(Core :: Graphics, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox89 | --- | affected |
People
(Reporter: denispal, Assigned: emilio)
References
Details
Attachments
(3 files)
When clicking on the "podcasts" link after navigating to https://music.amazon.com/, there is a 200ms flash of white which feels quite disruptive. This is without fission and happens with or without webrender.
There is a video describing the problem attached, and associated profile here if that's useful: https://share.firefox.dev/312lv9a
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 1•4 years ago
|
||
Ok, so this happens because by the time the paint suppression timer runs, the page is unstyled. So I think we should not unsuppress painting so soon, but detecting when to unsuppress it is an interesting problem... A good heuristic could be whether the background-color of the root element / body is not transparent. Or maybe we should paint the "default" canvas background if the page is loading and the canvas background is transpanent... That'd fix this for dark mode users, but not for everyone so that's not so great.
Assignee | ||
Comment 2•4 years ago
|
||
Actually the page in this case starts getting styled after the load
event, sometimes, but when that happens that also causes a white flash
in other browsers.
Updated•4 years ago
|
Assignee | ||
Comment 3•4 years ago
|
||
Baseline: https://treeherder.mozilla.org/jobs?repo=try&revision=046a42fa8669e35daad8199818958b6657d36929
Patch: https://treeherder.mozilla.org/jobs?repo=try&revision=cf852ed009c732c13765fff1962276bece4b6711
Comparison (eventually): https://treeherder.mozilla.org/perfherder/compare?originalProject=try&originalRevision=046a42fa8669e35daad8199818958b6657d36929&newProject=try&newRevision=cf852ed009c732c13765fff1962276bece4b6711&framework=10
Comment 5•4 years ago
|
||
Backed out changeset 1d4a266e0e49 (Bug 1699768) for causing multiple failures CLOSED TREE
Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&selectedTaskRun=aZgDhPfQSOWPUPdXdNymZQ.0&revision=1d4a266e0e49dc7bd12b9bfbf30ec4c40dd6464d
Failure log: https://treeherder.mozilla.org/logviewer?job_id=334132733&repo=autoland&lineNumber=1980
Range: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&selectedTaskRun=aZgDhPfQSOWPUPdXdNymZQ.0&resultStatus=success%2Ctestfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&fromchange=75e750d8ff501b363b214b204d948930db6269e4&searchStr=android%2C7.0%2Cx86-64%2Cwebrender%2Copt%2Cmochitests%2Ctest-android-em-7.0-x86_64-qr%2Fopt-geckoview-mochitest-plain-e10s%2C2&tochange=06b5568225ed50dae8b7dc0254ed45eae477eed7
Failure log: https://treeherder.mozilla.org/logviewer?job_id=334128840&repo=autoland&lineNumber=1655
Range: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&collapsedPushes=842382&selectedTaskRun=TKQ1MjL1Roms0qnPFyvCTg.0&resultStatus=success%2Ctestfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&fromchange=0bc442c1d8b9c3efa6361c3d83e47b1be4d48696&searchStr=android%2C7.0%2Cx86-64%2Cwebrender%2Cdebug%2Cweb%2Cplatform%2Ctests%2Ctest-android-em-7.0-x86_64-qr%2Fdebug-geckoview-web-platform-tests-e10s%2Cwpt15&tochange=c4571cca383292cfbe99bb35e7460569a74de071
Failure log: https://treeherder.mozilla.org/logviewer?job_id=334127918&repo=autoland&lineNumber=3009
Range: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&collapsedPushes=842382&selectedTaskRun=ZiduYeesRhWBYqobcgzRuw.0&resultStatus=success%2Ctestfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&fromchange=bba7c6c228da4449a1df243f5d3c211eec45cbad&searchStr=linux%2C18.04%2Cx64%2Casan%2Copt%2Cmochitests%2Ctest-linux1804-64-asan%2Fopt-mochitest-browser-chrome-e10s%2Cbc6
Backout: https://hg.mozilla.org/integration/autoland/rev/c4571cca383292cfbe99bb35e7460569a74de071
Assignee | ||
Comment 6•4 years ago
|
||
See the comments as for this might be unexpected. The tests could be
fixed but seems like footgunny, so for now this seems better.
For future reference, the line causing the events getting dispatched to
the wrong document is the IsPrimaryFramePaintSuppressed call in
PuppetWidget::GetCurrentWidgetListener(), which causes
widget->DispatchEvent from nsContentUtils::SendMouseEvent to dispatch
the event to the wrong page.
Assignee | ||
Updated•4 years ago
|
Comment 8•4 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/742356d5619b
https://hg.mozilla.org/mozilla-central/rev/38ecfb9d2fa0
Assignee | ||
Comment 9•4 years ago
|
||
Reopening since this will be backed out in bug 1701807 effectively :(
Updated•4 years ago
|
Comment 10•3 years ago
|
||
Denis, can you please re-test this with the current release and report whether the behavior still exists?
Reporter | ||
Comment 11•3 years ago
|
||
Seems like it's been addressed, thanks!
Description
•