MozAfterPaint-waiting code doesn't work unless dom.send_after_paint_to_content is true.
Categories
(Testing :: web-platform-tests, defect)
Tracking
(firefox138 fixed)
Tracking | Status | |
---|---|---|
firefox138 | --- | fixed |
People
(Reporter: emilio, Assigned: emilio)
Details
Attachments
(1 file)
So I was debugging some of the view transition reftest issues, and I realized that this code is broken.
It adds the event listener to the window
. But if dom.send_after_paint_to_content=false
, then it doesn't fire on the window and fires directly on the windowRoot.
So the right thing to do is adding the listener to the windowRoot, but then the question is why does it work in some cases or not others.
E.g. (not the --pref
vs. --setpref
typo), this timeouts consistently without this fix:
$ mach wpt --pref gfx.webrender.software=true --setpref remote.log.level="Debug" testing/web-platform/tests/css/css-view-transitions/sibling-frames-transition.html
While the --setpref
version works.
Assignee | ||
Comment 1•6 days ago
|
||
This doesn't change behavior in practice because
testing/profiles/common/user.js sets:
user_pref("dom.send_after_paint_to_content", true);
But avoids confusion and is the more correct thing to do. Also cleans up
a tiny bit.
Updated•6 days ago
|
Assignee | ||
Comment 2•6 days ago
|
||
Ok so I think --pref
somehow makes https://searchfox.org/mozilla-central/rev/917fb41190af26c3536ecc883212fc1e6710aa51/testing/profiles/common/user.js#39 not apply, that's a bit odd because it's not documented in --help
.
The good thing is that with that (I think with this) I can repro bug 1950791 consistently on Linux.
Comment 4•4 days ago
|
||
bugherder |
Description
•