Open Bug 723357 Opened 12 years ago Updated 1 year ago

Inconsistent rendering with unicode modifier and document.normalize()

Categories

(Core :: Layout: Text and Fonts, defect)

x86_64
macOS
defect

Tracking

()

Tracking Status
firefox-esr52 --- wontfix
firefox56 --- wontfix
firefox57 --- wontfix
firefox58 --- wontfix
firefox59 --- ?

People

(Reporter: jruderman, Unassigned)

References

Details

(Keywords: testcase)

Attachments

(2 files)

The testcase only shows "T" while the reference shows both "T" and the modifier. Strangely, increasing the font size makes the testcase match the reference.

document.normalize() shouldn't affect rendering, right? :)
Sounds like we don't do enough textrun reconstruction?
The dependence on size is very strange. It's not that _changing_ the size fixes things (by causing reflow/new textrun construction); simply adding font-size: 24px makes it display fine when initially loaded.
The problem seems to be font-specific. It happens with Arial, and also with Times New Roman; OTOH, with Tahoma and with Charis SIL, the modifier letter remains visible at all sizes.

(Not many fonts support that character, so I don't have a huge selection of fonts to test here - in most cases, fallback kicks in and we get Arial.)
Blocks: refdyn
WFM?
Jonathan, did you test with the fonts that comment 4 says are affected (and probably on the same platform)?
The bug still occurs for me with Nightly on macOS 10.12, with both Times New Roman and Arial: with the two-text-node testcase, the \uA721 character (MODIFIER LETTER STRESS AND LOW TONE) appears only if the font size is 20px or above.
Has Regression Range: --- → no
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.