Table testcase paints with cells too large (with white space around cell background) when restoring the default zoom level, from >200% zoom level
Categories
(Core :: Layout: Tables, defect)
Tracking
()
People
(Reporter: dholbert, Assigned: dshin)
References
(Regression)
Details
(Keywords: regression)
Attachments
(4 files, 1 obsolete file)
screenshot of buggy final rendering
STR:
- Load attached testcase (which is dshin's reference-case from https://phabricator.services.mozilla.com/D173031 )
- Zoom in as much as possible (500%), e.g.
Ctrl +orCtrl Mousewheel. - Restore the original zoom level with Ctrl+0
ACTUAL RESULTS:
The table paints with blank white space around the gray area in each cell, and with the cells larger than they should be.
EXPECTED RESULTS:
Table should paint as it did when first loaded.
I think this happens if you go to any zoom level > 200% (in step 2), from some brief testing (though it's easiest to see with 500%). The amount of white space (and table-cell-growth) seems to be ~proportional to how far above 200% you went.
Once you've triggered the bug, it'll go away if you trigger another zoom operation (e.g. Ctrl+ or Ctrl-)
|
Reporter | |
Comment 1•1 year ago
|
||
|
|
Reporter | |
Comment 2•1 year ago
|
||
|
|
Reporter | |
Comment 3•1 year ago
|
||
Regression range:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a73cc4e08bf5a005722c95b43f84ab0c8ff2bc7c&tochange=8645a74bbbd06b67699317df1abf3897db0e43d5
--> bug 895096
That makes sense, since it had to do with table border-collapse (used in the attached testcase) and the device-pixel-to-css-pixel ratio (which is what changes when you do full-page-zoom).
|
||
Comment 4•1 year ago
|
||
Set release status flags based on info from the regressing bug 895096
|
||
Updated•1 year ago
|
|
||
Updated•1 year ago
|
|
|
||
Updated•1 year ago
|
|
Assignee | |
Comment 5•1 year ago
|
||
|
||
Updated•1 year ago
|
|
|
||
Comment 6•1 year ago
|
||
Comment on attachment 9333637 [details]
Bug 1825384: Fix and simplify handling of empty rows when drawing border-collapsed tables. r=#layout-reviewers
Revision D178048 was moved to bug 1832110. Setting attachment 9333637 [details] to obsolete.
|
|
Assignee | |
Comment 7•11 months ago
|
||
So the problem happens here - where we determine that we don't need to recalculated collapsed borders. nsTableFrame::BCRecalcNeeded compares computed border style to determine if the recalculation is needed.
Computed border size this code receives does change until 200% zoom - e.g. at 100%, I see 600 au for border size, at 180%, 594 au, and at 190%, 576 au. At and after 200%, I only see 600 au.
|
|
Assignee | |
Comment 8•11 months ago
|
||
Hmmm. Seems that we presume the largest border collapse width data to enter is one we want to use, as seen here, which also is part of the problem...
|
|
Assignee | |
Comment 9•10 months ago
|
||
|
||
Comment 10•10 months ago
|
||
Pushed by dshin@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/c20fe6f0a048 Use app units in border-collapsed table data, not dev pixels. r=emilio
|
||
Comment 11•10 months ago
|
||
Backed out for causing table related reftest failures.
Failure log: https://treeherder.mozilla.org/logviewer?job_id=428704412&repo=autoland
Backout link: https://hg.mozilla.org/integration/autoland/rev/dcf391aec4e146f1abb2e7c4e0a5bc7d892150d6
|
|
Assignee | |
Comment 12•10 months ago
|
||
Hmmm... The test does uncover something odd, though I think this merely uncovered it?
If I run the test manually on Nightly 118 with 500% zoom, I see a similar failure.
Will dig further.
|
|
Assignee | |
Comment 13•10 months ago
|
||
Right, the problem goes back to bug 1825384 comment 8...
|
|
||
Comment 14•1 month ago
|
||
Pushed by dshin@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/e75d59152b39 Use app units in border-collapsed table data, not dev pixels. r=emilio
|
||
Comment 15•1 month ago
|
||
| bugherder | ||
|
||
Updated•1 month ago
|
Description
•