Closed
Bug 843585
Opened 12 years ago
Closed 12 years ago
two test cases are failing on ubuntu VMs
Categories
(Core :: Graphics, defect)
Core
Graphics
Tracking
()
RESOLVED
FIXED
People
(Reporter: jmaher, Assigned: jmaher)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
two of the localized-family-names tests fail (added in bug 602792), it seems to be that we fail on the SimSun fonts and the character U4f53. When I run on my local ubuntu 64 desktop, these tests pass, but I don't render the character that is causing problems. Here is what we see in the logs:
10:31:57 INFO - REFTEST TEST-UNEXPECTED-FAIL | file:///builds/slave/test/build/tests/reftest/tests/layout/reftests/font-matching/localized-family-names-003.html | image comparison (==), max difference: 255, number of differing pixels: 3370
10:31:59 INFO - REFTEST TEST-UNEXPECTED-FAIL | file:///builds/slave/test/build/tests/reftest/tests/layout/reftests/font-matching/localized-family-names-004.html | image comparison (==), max difference: 255, number of differing pixels: 6475
Here is where you can see a tbpl view for reftest analyzer and moar logs:
https://tbpl.mozilla.org/?tree=Cedar&rev=9f0cfef0e54a
This happens on all runs of R and Ru and very consistently. I can reproduce this by hand on a VM. These tests were not failing when we had a different kernel, but now we have an acceptable kernel (linux-generic) and these tests started failing.
Assignee | ||
Comment 1•12 years ago
|
||
I always put the original bug which introduced the test cases as depends on since most likely whatever what done in the original bug would affect what is going on with the current problem.
If you know what is going on with these test cases and why it shouldn't be related to the bug where the tests were added, please add more information here so we can quickly resolve this and speed up our wait times on linux slaves by running reftests on a VM.
Depends on: 602792
Comment 2•12 years ago
|
||
The actual code changes in bug 602792 were Windows-specific, so they shouldn't be a factor here, but the tests are run on all platforms, and on inspection, they look a bit fragile. It's hard to avoid that, inasmuch as they're testing how we access specific fonts on the platform, but different platforms/versions may have differing collections of fonts, or different versions of the "same" fonts.
I think there are a couple of possible reasons for the tests failing here: either (a) lookup of localized family names isn't working properly on Linux, which could be either a Gecko bug or a fontconfig one; or (b) the code is working fine, but the particular fonts available on these systems don't have exactly the same localized names as the testcase expects, and so either the test or the reference fails to find the expected font.
My guess is that in this particular case, the tests are failing due to some difference in fontconfig aliases, fallback behavior, etc. between various Linux configurations. FWIW, I get a similar failure in my Ubuntu64 VM (though not identical to the reftest screenshots in the Cedar logs), and checking confirms that the SimSun font (for example) is not available, so fontconfig is stepping in to give us something else - but behaves differently depending whether we asked for "宋体" or "SimSun".
Unless jdaggett disagrees, I'd suggest just marking those tests as random on Linux; as long as we're relying on fontconfig to do font-matching, exactly what will do is too obscure (and too far out of our direct control) for me to care about the details.
Assignee | ||
Comment 3•12 years ago
|
||
Most likely this is an issue with packages or settings on the VM. If we say the tests will run on Ubuntu 12.04 (our soon to be and already partially used testing platform), then we will have to account for different packages, settings and configurations.
I am fine marking this as random-if or finding the specific package to make this work. Whatever you guys determine is a good solution going forward.
Thanks for the details on this!
Comment 4•12 years ago
|
||
Yes, fontconfig comes with aliases for SimSun, NSimSun, and Sazanami Gothic, but not their localized names.
The tests should pass if the relevant fonts are installed and Sazanami fonts are available, but SimSun and NSimSum are not available AFAIK.
I expect the tests should actually pass if the family name lists are modified to include an appropriate fallback generic. Something like:
font-family: "NSimSun", monospace
font-family: "Sazanami Gothic", sans-serif
font-family: "SimSun", sans-serif
and similarly for the localized names.
Assignee | ||
Comment 5•12 years ago
|
||
I ran this locally on a ubuntu VM that we use for testing and it passed, same with my desktop.
Comment 6•12 years ago
|
||
Comment on attachment 718407 [details] [diff] [review]
add monospace/sans-serif to the questionable fonts (1.0)
Sorry, I didn't recall until today that Gecko always appends a generic family anyway when there is none specified. It seems the reason for the failure is more complicated than I first suspected.
Gecko asks fontconfig for the best match to NSimSun, serif.
Fontconfig believes NSimSun is a monospace font and so modifies the list of families to include a "monospace" fallback. The list becomes NSimSun, serif, monospace. This does not happen with the localized name.
"NSimSun, serif" and "NSimSun, serif, monospace" should both find the same font if one of fontconfigs default "serif" fonts supports the characters. Apparently none of the default "serif" fonts that support these characters are installed, but I suspect one of the default "monospace" fonts is installed.
This modification to the test is probably just passing because it is mimicking what fontconfig does, and that doesn't really feel like the appropriate fix.
Are you able to try installing http://packages.ubuntu.com/precise/ttf-sazanami-mincho please? That is one of fontconfigs default "serif" fonts. It is Japanese rather than Chinese, but I don't know enough about these characters to know whether any are distinctly Chinese or Japanese. Sazanami Mincho is one of the fonts being tested by localized-family-names-004.html, so seems a good font to install anyway.
Attachment #718407 -
Flags: review?(karlt)
Assignee | ||
Comment 7•12 years ago
|
||
I have verified that addding ttf-sazanami-mincho resolves this problem!
Comment 8•12 years ago
|
||
Woot!
Joel, can you try to verify that it works fine on the production machines as well. I deployed the font in bug 845834.
Assignee | ||
Comment 9•12 years ago
|
||
these are running great on cedar, we will close this as fixed.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•