WPT failure in css/css-text/tab-size/tab-min-rendered-width-1.html
Categories
(Core :: Layout: Text and Fonts, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox118 | --- | fixed |
People
(Reporter: twisniewski, Assigned: jfkthame)
References
()
Details
Attachments
(1 file)
We are failing this test as the 0.7625ch tab size isn't rendering as expected. WebKit 175 recently aligned with Chrome on this test, so it would be good to find out what's going on here.
Comment 1•1 year ago
|
||
Jonathan you added this test and it seems to pass in automation, mind taking a look?
Comment 2•1 year ago
|
||
Test passes locally on Linux here. Hopefully just a test bug?
Assignee | ||
Comment 3•1 year ago
|
||
The failure is on the line where the initial span on the line has width: 7.5ch
, so then the effective width of the tab should be exactly 0.5ch and it shouldn't need to skip to the next tab-stop. But depending on the font in use, the computation of widths in ch
units may involve floating-point inaccuracies, and this is potentially making it look as though the tab width ends up fractionally less than 0.5ch.
To avoid this, I guess we could make the testcase use a known font like Ahem, with a size where the ch
unit will compute to an exact number of pixels and floating-point width computations shouldn't cause an issue.
Assignee | ||
Comment 4•1 year ago
|
||
Updated•1 year ago
|
Assignee | ||
Comment 5•1 year ago
|
||
This should make the test less fragile with respect to floating-point ch
-width computations.
Comment 6•1 year ago
|
||
I can reproduce the failure locally, and I confirmed the patch fixes it for me. \o/
(Interesting that it doesn't reproduce on TreeHerder; font-specific stuff I guess.)
Comment 9•1 year ago
|
||
bugherder |
Description
•