Intermittent /css/css-flexbox/overflow-auto-001.html | Testing http://web-platform.test:8000/css/css-flexbox/overflow-auto-001.html == http://web-platform.test:8000/css/reference/ref-filled-green-100px-square.xht
Categories
(Core :: Layout: Text and Fonts, defect, P5)
Tracking
()
People
(Reporter: intermittent-bug-filer, Unassigned)
References
Details
(Keywords: intermittent-failure, regression)
Attachments
(1 file)
|
1.88 KB,
image/png
|
Details |
screenshot of the problematic piece of the testcase snapshot
Filed by: btara [at] mozilla.com
Parsed log: https://treeherder.mozilla.org/logviewer.html#?job_id=269387970&repo=autoland
Full log: https://queue.taskcluster.net/v1/task/HqP0RBjtR-qd20oBdPL9LA/runs/0/artifacts/public/logs/live_backing.log
Reftest URL: https://hg.mozilla.org/mozilla-central/raw-file/tip/layout/tools/reftest/reftest-analyzer.xhtml#logurl=https://queue.taskcluster.net/v1/task/HqP0RBjtR-qd20oBdPL9LA/runs/0/artifacts/public/logs/live_backing.log&only_show_unexpected=1
[task 2019-10-02T09:41:57.489Z] 09:41:57 INFO - TEST-START | /css/css-flexbox/overflow-auto-001.html
[task 2019-10-02T09:41:58.130Z] 09:41:58 INFO - TEST-UNEXPECTED-FAIL | /css/css-flexbox/overflow-auto-001.html | Testing http://web-platform.test:8000/css/css-flexbox/overflow-auto-001.html == http://web-platform.test:8000/css/reference/ref-filled-green-100px-square.xht
[task 2019-10-02T09:41:58.130Z] 09:41:58 INFO - Found 8838 pixels different, maximum difference per channel 255
[task 2019-10-02T09:41:58.130Z] 09:41:58 INFO - REFTEST IMAGE 1 (TEST): [data URI omitted for brevity]
[task 2019-10-02T09:41:58.131Z] 09:41:58 INFO - REFTEST IMAGE 2 (REFERENCE): [data URI omitted for brevity]
[task 2019-10-02T09:41:58.131Z] 09:41:58 INFO - TEST-INFO took 637ms
|
||
Comment 1•6 years ago
|
||
In the reftest screenshot, you can see that the issue is with the bold descriptive-text <strong>no red</strong> -- we're adding a lot of bonus spacing around each character in that string for some reason.
(I wanted to guess that this was a version of bug 1392106, but in this case the test failure was on Android, so it's unrelated.)
jfkthame, do you know what might be going on here?
|
|
||
Comment 2•6 years ago
|
||
|
||
Comment 3•6 years ago
|
||
(In reply to Daniel Holbert [:dholbert] from comment #1)
In the reftest screenshot, you can see that the issue is with the bold descriptive-text
<strong>no red</strong>-- we're adding a lot of bonus spacing around each character in that string for some reason.(I wanted to guess that this was a version of bug 1392106, but in this case the test failure was on Android, so it's unrelated.)
jfkthame, do you know what might be going on here?
It looks to me like the bold "no red" text has been measured as if the font size were twice as big as it should be, or thereabouts, so that the glyph advances are doubled, although the glyphs themselves are rendered at the expected size. (Note how the line-height also appears to be a lot bigger in the test snapshot than in the reference. A doubled font-size for the bold span would cause something like that, I guess.)
I don't really have any idea how this would have happened.... I'm a bit suspicious, given it's just happened recently, that it could be related to the changes in freetype font management & glyph metrics handling that lsalzman has been doing; maybe there's something flaky there. That would be bug 1547063 and associated bugs. Lee, any ideas?
|
||
Comment 4•6 years ago
|
||
(In reply to Jonathan Kew (:jfkthame) from comment #3)
(In reply to Daniel Holbert [:dholbert] from comment #1)
In the reftest screenshot, you can see that the issue is with the bold descriptive-text
<strong>no red</strong>-- we're adding a lot of bonus spacing around each character in that string for some reason.(I wanted to guess that this was a version of bug 1392106, but in this case the test failure was on Android, so it's unrelated.)
jfkthame, do you know what might be going on here?
It looks to me like the bold "no red" text has been measured as if the font size were twice as big as it should be, or thereabouts, so that the glyph advances are doubled, although the glyphs themselves are rendered at the expected size. (Note how the line-height also appears to be a lot bigger in the test snapshot than in the reference. A doubled font-size for the bold span would cause something like that, I guess.)
I don't really have any idea how this would have happened.... I'm a bit suspicious, given it's just happened recently, that it could be related to the changes in freetype font management & glyph metrics handling that lsalzman has been doing; maybe there's something flaky there. That would be bug 1547063 and associated bugs. Lee, any ideas?
I'm not sure why the advance would get mysteriously inflated here. Theoretically, if there was a problem loading the advance width, it would just result in a zero advance, or might this also be symptomatic of wrong glyph bounds too (which should still be zero on failure)? The face locking keeps any other user from coming in and modifying the FT_Face's selected size while we're getting all the metrics, unless FT_Set_Char_Size can intermittently fail somehow for reasons we don't yet understand... And then there is the question of whether the metrics are even using the right font in the first place, which might suggest something higher in font selection, maybe?
|
|
||
Comment 5•6 years ago
•
|
||
This seems to be a new category of intermittent bugs, cropping up in random tests...
Added two "see also" similar bugs (both of them with characters overlapping [i.e. not-enough-spacing] rather than too-much-spacing as was the case here). The former one is on Linux and the latter is on Android.
| Comment hidden (Intermittent Failures Robot) |
|
||
Comment 7•6 years ago
|
||
https://wiki.mozilla.org/Bug_Triage#Intermittent_Test_Failure_Cleanup
For more information, please visit auto_nag documentation.
Description
•