Closed Bug 468217 Opened 16 years ago Closed 3 years ago

reftests/font-face/sheet-set-switch-1 fails on mac

Categories

(Core :: Graphics, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME
87 Branch
Tracking Status
firefox87 --- fixed

People

(Reporter: karlt, Assigned: jfkthame)

References

Details

Attachments

(4 files)

      No description provided.
Attached image reference png (gtk)
Hmmm.  It works for me, with your patch, though.
Attached image test png (gtk)
The C appears to be positioned 1 pixel to the left of position of the Y.

(The test passes on my system.)
I guess it seems most likely to be a text run separation issue, that could probably be fixed by changing the test.

Unlikely to be fixed by the remaining patch I have in my tree (bug 458878).
This test has been failing for me and Jonathan Kew on Mac too.
Er, wait, the images you attached look like sheet-set-switch-1, not sheet-set-base-1.  Which one is failing on the Linux tinderbox?   (And is it the same one that's failing on Mac for roc and Jonathan Kew?)
Sorry, I was mistaken --- it's sheet-set-switch-1 that's failing for us on Mac.
It's also sheet-set-switch-1 that Karl marked random on GTK2 in the reftest.list.
Summary: reftests/font-face/sheet-set-base-1 fails on gtk → reftests/font-face/sheet-set-switch-1 fails on gtk
Can we mark sheet-set-switch-1 as random on Mac too, since it fails there for me and Jonathan?
I tried running valgrind on this, and I didn't get any warnings (without the patch from bug 476724).

Bug 476724 could be the cause of the randomness on Mac.
Traced this down for bug 476724, see:

https://bugzilla.mozilla.org/show_bug.cgi?id=476724#c21

Basically the Mark2B and MarkXMark2Y fonts have differing underline offsets.  The reference would be identical if it simply uses Mark2C, MarkB and the body text 'ACB'.
Or another solution would be to explicitly set the metrics in the python script that creates the markXX fonts, then check in corrected versions of these.
(In reply to comment #12)
> Or another solution would be to explicitly set the metrics in the python script
> that creates the markXX fonts, then check in corrected versions of these.

I couldn't find an API that let me do this, although changing the vertical extents of the glyphs to match fixed it.

That said, I think we could be testing useful things by having them different, so I'm inclined to scratch markXmark2Y and rewrite the references that use it.
Assignee: mozbugz → dbaron
Attachment #360821 - Flags: review?(jdaggett) → review+
Comment on attachment 360821 [details] [diff] [review]
patch

Looks good.
http://hg.mozilla.org/mozilla-central/rev/c592bbe68cc7
... but it still fails on Mac (should have tested on my own Mac too; I think I was doing too many things at once last night)...
http://hg.mozilla.org/mozilla-central/rev/97867f9b4e42
Worse, it's actually still random on Mac (and I've seen it both ways on my Mac).
http://hg.mozilla.org/mozilla-central/rev/3362518abdc0
Is this bug fixed?
The test is still marked as random on Mac in the manifest.
OS: Linux → Mac OS X
Summary: reftests/font-face/sheet-set-switch-1 fails on gtk → reftests/font-face/sheet-set-switch-1 fails on mac
Attachment #351663 - Attachment description: reference png → reference png (gtk)
Attachment #351664 - Attachment description: test png → test png (gtk)
See Also: → 1356158

This doesn't seem to be an issue any longer; I tried removing the annotation and running a bunch of test jobs on try, and didn't see any failures.

https://treeherder.mozilla.org/jobs?repo=try&revision=5548dd8bc067ceceb488745770766b0e3b779a6f

So I think we can just remove the random annotation and close this as WFM.

Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
Pushed by jkew@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/739de847efd4
Remove reftest annotation for test that no longer seems to fail randomly. r=hiro
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 87 Branch

WORKSFORME is a better resolution than FIXED here, I think, as we don't actually know when the underlying issue was fixed.

Resolution: FIXED → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: