Closed Bug 420913 Opened 12 years ago Closed 9 years ago

OS X 10.5 unexpectedly failing file:///build/slave/trunk_leopard/mozilla/layout/reftests/bidi/386339.html

Categories

(Core :: Layout, defect)

PowerPC
macOS
defect
Not set

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: rcampbell, Assigned: jtd)

References

()

Details

Attachments

(5 files, 1 obsolete file)

Attached file bidi 386339 data (obsolete) —
see qm-xserve02 on mozillatest tinderbox
Component: Layout → Layout: BiDi Hebrew & Arabic
QA Contact: layout → layout.bidi
Do the testcases in bug 361695 work on OSX 10.5?
Component: Layout: BiDi Hebrew & Arabic → Layout
they appear to for me.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b4pre) Gecko/2008030304 Minefield/3.0b4pre ID:2008030304
Component: Layout → Layout: BiDi Hebrew & Arabic
Component: Layout: BiDi Hebrew & Arabic → Layout
QA Contact: layout.bidi → layout
This works for me, both on 10.4 and 10.5.  Does the box lack Hebrew fonts or something?  Attached testcase can be used to iterate through the fonts on the machine for which this occurs, if it can be reproduced elsewhere.
(In reply to comment #5)
> Does the box lack Hebrew fonts or something?

Hmm, not thinking straight, it obviously has some Hebrew fonts, the question is which set.  And is there an existing profile used that contains specific pref font settings that are different than the default? (see user.js in profile folder, search for "font.").

I don't see this running a 10.4 build through reftest on my 10.5 machine, fwiw.
Seeing this on the new mozilla-1.9.1 unit test mac (bm-xserve22). This machine may have been qm-xserve02 in a past life. It's been reimaged, though, so I would expect whatever font problems or w/e.

Which specific fonts should I look for to confirm this?
Attached file updated reftest data
The data format has changed since robcee's attachments were made, so here's
something that reftest-analyzer, etc., can parse (from the log in bug 420911 comment 4).
Attachment #307279 - Attachment is obsolete: true
I traced this down a little more today.  The cause is that the fix for bug 361695 doesn't always work.  The root cause is that ATSUI will do glyph mirroring *if* the font has a 'prop' table that contains entries for the right set of glyphs.  The fix for bug 361695 was to do glyph mirroring manually if the font lacked a 'prop' table.  The problem here is that some fonts have a 'prop' table but lack entries for characters like '<' and '>'.  Many CJK fonts (e.g. Hiragino Kaku Gothic Pro) lack these.

For now, I think we should mark this reftest as 'random' on Mac and fix the underlying problem when we have a chance.
As in the reftest case, a less-than sign should appear as a greater-than sign in RTL text.  All the fonts listed from "Al Bayan" on are fonts that have 'prop' tables on 10.5.
I've been doing some testing with CoreText, and my impression so far is that it handles mirroring correctly regardless of whether the font has a 'prop' table. All the fonts in your attached testcase display properly on 10.5 on Minefield + my current CoreText patch.

So when we move to CoreText this should be resolved. I'll attach an updated patch to bug 389074 (use CoreText instead of ATSUI) shortly, after a little more testing.
Great!  Trying to parse the 'prop' table to figure out whether the right set of mirror data is available would absolutely *suck*.  We could also just blacklist the specific fonts in question, but probably more trouble than it's worth.
Agreed -- I don't think we should try to do anything for the ATSUI case, which will become obsolete when we leave 10.4 behind. It's a platform bug that isn't worth the effort to work around, especially as the fonts concerned aren't likely to be used in RTL contexts very much anyway. (And FWIW, our existing behavior is no worse than Safari, which has the same problem.)
Fonts were not present on bm-xserve22 and once copied over from moz2-darwin9-slave05 (after doing a diff on /Library/Fonts between the two) this test passed.

Closing.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Comment on attachment 350292 [details] [diff] [review]
patch, v.0.1, make 386339 random on OS X

When tests are marked as random, it's good to put a comment at the end of the line pointing to the bug number, and have a comment in the relevant bug saying which tests are marked random.  That makes it a little more likely we'll undo the marking-random when the underlying bug is fixed.
I'm reopening because this is still going to be a problem for developers running tests in locales where default fonts contain a morphing table without glyph mirroring information for the characters in this reftest. 

Ex: Mac OS X Japanese locale where UTF-8 encoded pages will use Hiragino Kaku Gothic Pro for fallback.
Assignee: nobody → jdaggett
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Once we fix bug 389074 (I'm working on it...), this should be resolved regardless of available fonts, but only for OS X 10.5 and later, not 10.4. Does the test framework allow us to make that distinction, marking the test as random only when running on 10.4?
I'm going to mark this as not blocking the Firefox 3.1 branch anymore since we fixed up the Macs there.
No longer blocks: 464640
WFM base on comment 19.
Status: REOPENED → RESOLVED
Closed: 11 years ago9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.