Closed Bug 611855 Opened 10 years ago Closed 10 years ago
h1 and h2 headers are displayed in italic (after OS X 10
.6 .5 update)
314 bytes, text/html
1.17 KB, patch
|Details | Diff | Splinter Review|
1.60 KB, patch
|Details | Diff | Splinter Review|
Firefox 4 Beta 7 H1 and H2 headers display text in italic even when specific to display text as normal. Examples: http://www.johnwaynehill.com/blog/ http://bjoyski.com/blog/ Neither of these headers (large green and orange links) should be in italic, but they are.
Please attach a testcase, otherwise a layout bug should be UNCONFIRMED rather than NEW. The appropriate Product/Component for this bug is Core/Layout (I think).
This appears to be specific to 'helvetica', combined with 'font-weight: lighter'. I can reproduce that on Gecko 1.9.2 (at least back to 2010.06.15 builds) and Gecko 2.0.
Component: General → Layout: Text
Product: Firefox → Core
QA Contact: general → layout.fonts-and-text
disable either 'helvetica' or 'font-weight: lighter' and the text displays normally. Firebug says that the computed style for font-style is 'normal'.
Tested on 10.6.5 works Gecko/20090816 Minefield/3.7a1pre http://hg.mozilla.org/mozilla-central/rev/ef2e4699b319 fails Gecko/20090817 Minefield/3.7a1pre http://hg.mozilla.org/mozilla-central/rev/d9742d839d7d http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ef2e4699b319&tochange=d9742d839d7d --> bug 493280 ? I can't reproduce this on OS X 10.5. Did this display correctly on versions of OS X 10.6 prior to 10.6.5 ? I don't remember ever seeing this with a bunch of test cases I have on my local server.
I can't reproduce in Ubuntu 10.10
I can't reproduce, using 10.6.4.
The 10.6.5 release notes contains this snippet: 'Resolves spacing issues with OpenType fonts'. http://support.apple.com/kb/HT4250 The security part of the package also mention changes to ATS. http://support.apple.com/kb/HT4435
Confirmed that this does not happen with 10.6.4, but does after updating to 10.6.5. The issue seems to be that 10.6.5 introduces new Light and LightOblique faces of Helvetica, but Cocoa does not return correct font-traits for the LightOblique face. It fails to set the NSItalicFontMask bit in the traits entry of the array returned by [availableMembersOfFontFamily] (even though the italic bit IS set in the macStyle field of the 'head' table), and so our code sees both the Light and LightOblique faces as having identical attributes, and the oblique one happens to "win".
We need to get a bug reported to Apple here, right? No matter what we do?
Yes. Filed rdar://8666610. Note that the underlying problem can also be demonstrated using TextEdit.app, as follows: 1. Launch TextEdit, and enter "Hello World" in a new document. Select all the text, and open the Fonts panel. 2. Click on the Helvetica family: the text will appear in Helvetica Regular, as expected. 3. Click on the Light face: text changes to Helvetica Light, as expected. 4. Now press Command-I to apply italic (or oblique) style: text changes to Helvetica Oblique (i.e. in Regular weight) instead of the expected Helvetica Light Oblique. 5. Click on the Light Oblique face, to explicitly choose Helvetica Light Oblique: displays correctly. 6. Now press Command-I to toggle the oblique style off: text changes to Helvetica Oblique instead of the expected Helvetica Light. (And pressing Command-I again then changes to Helvetica Regular.)
Although this is really an Apple bug, I think it's worth adding a small workaround in our code so that people don't end up with unexpected italics like this. The reports here show that it's an issue that occurs "in the wild" on real sites. This patch just checks whether the style name ends with "Italic" or "Oblique", and marks the face as italic even if the relevant font-traits bit was not set. (Note that the NSFontManager documentation specifies that the style name is NOT localized, so just checking the English names should be OK here.) An alternative would be to load the 'head' table and check the macStyle field, but I'm inclined to go for the simplest code at this point.
Assignee: nobody → jfkthame
Attachment #490462 - Flags: review?(jdaggett)
Comment on attachment 490462 [details] [diff] [review] patch, v1 - check style name in case 'italic' traits not set properly Looks like this only affects Helvetica Light Italic. Weirdly, the font name table has "Helvetica Light Oblique", maybe this name table oddness that relates to the problem. All the other italic flags (macStyle in 'head', fsSelection in 'OS/2') look like they're set correctly. I completely hate the idea of putting in this sort of thing to fix a single font but I guess it's the best we can do. I imagine fixing this will be a low priority at Apple.
Attachment #490462 - Flags: review?(jdaggett) → review+
(In reply to comment #12) > Looks like this only affects Helvetica Light Italic. Weirdly, the font name > table has "Helvetica Light Oblique", maybe this name table oddness that relates > to the problem. All the other italic flags (macStyle in 'head', fsSelection in > 'OS/2') look like they're set correctly. Yes, I checked those thinking it could be a bug in the actual font, but couldn't find a cause there. Which makes me suspect that it's a bug in how the Cocoa font system manages families and faces, and so it could potentially affect other families as well if they happen to have the right collection of faces to stumble on the error. > I completely hate the idea of putting in this sort of thing to fix a single > font but I guess it's the best we can do. I imagine fixing this will be a low > priority at Apple. Yup, I'm afraid so. It's not the first time we've had to do such a thing - and probably won't be the last! The one "good" thing in this case is that the bug manifests as user-visible incorrect behavior in Apple apps such as TextEdit, too.
Comment on attachment 490462 [details] [diff] [review] patch, v1 - check style name in case 'italic' traits not set properly Requesting approval to land for 2.0, as this causes incorrect styling on real-world sites, and OS X 10.6.5 will rapidly become widespread via Apple Software Update, so that an increasing number of users will see the bug.
Attachment #490462 - Flags: approval2.0?
Can we get this on Gecko 1.9.2 as well, please ?
Not going to block a branch release on this, but if you get it tested on the trunk and request branch approval we can consider taking it in a branch release. Code-freeze for the current release is Thursday this week (11/18).
Attachment #490462 - Flags: approval2.0? → approval2.0+
Pushed to trunk: http://hg.mozilla.org/mozilla-central/rev/fedc658ef505
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
This is the patch for 1.9.2 (it's the same code, just moved around a bit). Requesting approval to land on branch so that we don't get the incorrect font selection in FF3.6 on the latest OS X update.
Attachment #490842 - Flags: approval188.8.131.52?
Comment on attachment 490842 [details] [diff] [review] patch for 1.9.2 branch a=LegNeato for 184.108.40.206. Should we take this on 1.9.1 as well?
Attachment #490842 - Flags: approval220.127.116.11? → approval18.104.22.168+
(In reply to comment #19) > Comment on attachment 490842 [details] [diff] [review] > patch for 1.9.2 branch > Should we take this on 1.9.1 as well? 1.9.1 is not affected
Pushed to 1.9.2: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/28d98b480e3d
You need to log in before you can comment on or make changes to this bug.