Open f.e. SMS app: - Execute: document.querySelector('#messages-input').textContent = 'Hello ɛ̂ world' - Output: Hello ɛ^world The ^ thing is now above the next char, not on the right one.

This is actually Fira Sans (but yeah, I reproduce in Firefox using the font). Hey Stephany, do you know who we should ping for font issues?

Safari handles this correctly. I see: Hello ɛ̂ world. Chrome behaves like Firefox. So it seems like a Gecko bug to me.

Somebody pointed to me that a screenshot would be more reliable.

I think this could be an edge case in Fira that exhibits a difference in behaviours. So maybe we need to fix Fira and Gecko. Jonathan: Do you have an idea what's happening here?

Fira Sans doesn't include the ɛ character, so font fallback picks something else; it generally won't look very good, and the diacritic won't combine properly because it will still be rendered using Fira. The Safari screenshot looks better because it happens to pick a font (Helvetica?) that is visually quite close to Fira in weight; and I think it applies fallback to the entire base+diacritic cluster (note that the circumflex accent in Fira is rather wider and flatter than what appears in the Safari screenshot). The fix here is to fill out the character repertoire in Fira, so that we don't hit fallback on occasional letters within the text. This should be part of completing the extended-Latin-script coverage in the fonts. cc'ing Patryk, as our liaison with the font designers.

We would see a somewhat better result here if we completed bug 543200, but that's potentially tricky to make both fully correct and performant, given the possibilities of both precomposed and partially or fully decomposed base+diacritic combinations. As an interim measure to mitigate this, perhaps we could do a lightweight modification to font matching, such that we try to avoid font changes between a base character and its diacritics. So if the base character hits font fallback, we'll try to use the same font for any following accent. (Though if the fallback font used for the base character doesn't support the accent needed, we'd still lose.) I've filed bug 1130429 for that possible platform enhancement, though it doesn't remove the need to complete the character coverage of the Fira fonts so as to avoid fallback issues altogether.

Flagging Patryk on fonts.

This character is being added to Fira in the next update which is slated to be released in the next few weeks.

[Blocking Requested - why for this release]: This blocks bug 1128905, which has blocking-b2g 2.0+...

Hey Jan, it looks like bug 1128905 covers 2 issues: one is the autocorrect issue (the original issue the bug was filed for), the other is the keyboard display issue (the issue you found while investigating). So I object this blocks bug 1128905. We clearly have 2 different bugs. This could still be a blocker, but not for this reason.

[Triage] de-tag given current 2.0 phase, and the symptom.

Firefox OS is not being worked on