Investigate running our fragmentation reftests a second time, this time through the printing codepaths
Categories
(Core :: Printing: Setup, task, P2)
Tracking
()
People
(Reporter: jwatt, Assigned: hiro)
References
()
Details
(Whiteboard: [frag2020_v79][layout:backlog])
We've had printing regressions that our fragmentation reftests should have caught but didn't because we don't run them through the printing code paths. We should investigate what it would take to run them through as much of the printing codepaths as we can get them to.
Reporter | ||
Updated•4 years ago
|
Assignee | ||
Comment 1•4 years ago
|
||
I believe the [jgraham's print machinery] uses FrameLoader.print which means tests with the machinery run through the printing code paths. Also that the wpt print machinery compares all output pages instead of just comparing first few pages. So I am pretty sure once after the wpt print machinery has been merged into our tree and started running our reftest-paged reftests with the machinery, it would be sufficient.
That said, as of now it's hard to identify each problem in each reftest-paged reftest which fails with the wpt printing machinery, since bug 1626129 obscures the problems (at least for me). So we should re-evaluate reftest-paged reftests once after bug 1626129 was fixed.
Anyways, I will close this bug once the jgraham's PR has been merged into m-c, and will open bugs to migrate our reftest-paged reftests in wpt.
Reporter | ||
Updated•4 years ago
|
Updated•4 years ago
|
Reporter | ||
Updated•4 years ago
|
Assignee | ||
Comment 2•4 years ago
|
||
Closing, this will be superseded by bug 1645272.
Description
•