1947151 - www.admesy.com - 3-em dash not displayed

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect, P1)

Description

[Calin Tanase]

Environment:
Operating system: Windows 11/10
Firefox version: FIrefox 134/135/137

Steps to reproduce:

1. Go to https://www.admesy.com
2. Observe the header of products in the slider.

Expected Behavior:
3-em dash is displayed correctly.

Actual Behavior:
3-em dash is not rendered.

Notes:

• Personally I was not able to reproduce but I moved the issue since it seems to affect more users
• Reproduces regardless of the status of ETP
• Reproduces in firefox-nightly, and firefox-release
• Does not reproduce in chrome

Created from https://github.com/webcompat/web-bugs/issues/146829

Comment 1

[Calin Tanase]

Attachment: original reporter screenshot.png

Comment 2

[Alice0775 White]

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=6840cc3786ac4ce90558c0082c0dae5cd1f997a5&tochange=73ae30d15fdda0ab65c7315f970a9d483359e29d

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1928012

:jfkthame, since you are the author of the regressor, bug 1928012, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 4

[Jonathan Kew [:jfkthame]]

The webfont the site is using doesn't include the 3-em dash character, and so this character ends up hitting global font fallback. The affected users must have a font installed that "supports" this codepoint, but the glyph it provides is a kind of "placeholder" representing the codepoint rather than a "real" 3-em-dash glyph. (Note that the box in the screenshot is not the missing-glyph box we generate for characters that lack any font at all; it's a glyph from an actual font on the system.)

I'm not sure what font that is -- it doesn't happen for me on my Win10 machine -- but with multiple users affected, it must be something reasonably common. (The DevTools Inspector on an affected system would be able to reveal what font it is.)

Anyhow, I think we can fix this by adding Segoe UI (which supports this and various other less-common punctuation) to the default "common fallback fonts" on Windows, so that it gets checked ahead of the broader (and less-predictable) global fallback search.

Comment 5

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1947151 - Include Segoe UI in (script-independent) common fallback fonts, for better punctuation coverage. r=#layout

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9ab4bfbf0303
Include Segoe UI in (script-independent) common fallback fonts, for better punctuation coverage. r=TYLin

Comment 7

[Atila Butkovits]

Backed out for causing failures at css3-counter-styles-161.html.

Backout link: https://hg.mozilla.org/integration/autoland/rev/21c19b0faa1361e9836382f62accd328dadc4ce3

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=9ab4bfbf03031e1250fce587bcc66ca87d188817

Failure log: https://treeherder.mozilla.org/logviewer?job_id=494513230&repo=autoland&lineNumber=7985

Comment 8

[Pulsebot]

Backout by [e-mail]:
https://hg.mozilla.org/mozilla-central/rev/11a45cb6835c
Backed out changeset 9ab4bfbf0303 for causing failures at css3-counter-styles-161.html. CLOSED TREE

Comment 9

[Jonathan Kew [:jfkthame]]

Looks like the patch had an effect on font selection (fallback) in the Khmer counter-styles tests. I can't reproduce this locally -- the test passes fine on my Win10 machine -- but it looks like I'm getting a different Khmer font altogether than the screenshot from CI shows. The (Win11) test machines must have a different font configuration than I have, and fallback is giving different results (though they're not really "wrong", just unpredictable).

The same is happening to the Lao counter-styles tests, too.

It may help if we set appropriate lang attributes on the test elements, to provide a hint to the browser's font selection, rather than leaving the content tagged as "English" and relying purely on fallback to handle the non-Latin characters. I'll push a try job and see what happens...

Comment 10

[Jonathan Kew [:jfkthame]]

(In reply to Jonathan Kew [:jfkthame] from comment #9)

It may help if we set appropriate lang attributes on the test elements...

That didn't help, there's still an odd effect on the Khmer and Lao tests. I think the safest way forward here, then, is to limit the addition of Segoe UI to punctuation & symbol codepoints, which is closer to the pre-bug 1928012 setup.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c8f787aa78c5
Include Segoe UI in (script-independent) common fallback fonts, for better punctuation coverage. r=TYLin

Comment 12

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/c8f787aa78c5

Comment 13

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:jfkthame, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox136 to wontfix.

For more information, please visit BugBot documentation.

Comment 14

[Jonathan Kew [:jfkthame]]

This seems minor/rare enough that I don't think uplift is necessary.

Comment 15

[Thorin [:thorin]]

(In reply to Jonathan Kew [:jfkthame] from comment #4)

I'm not sure what font that is -- it doesn't happen for me on my Win10 machine -- but with multiple users affected, it must be something reasonably common. (The DevTools Inspector on an affected system would be able to reveal what font it is.)

Segoe UI Symbol

Comment 16

[Jonathan Kew [:jfkthame]]

(In reply to Thorin [:thorin] from comment #15)

(In reply to Jonathan Kew [:jfkthame] from comment #4)

I'm not sure what font that is -- it doesn't happen for me on my Win10 machine -- but with multiple users affected, it must be something reasonably common. (The DevTools Inspector on an affected system would be able to reveal what font it is.)

Segoe UI Symbol

Oh, interesting -- thanks! I have Segoe UI Symbol on Win10, but my version doesn't include that codepoint; must be an update in Win11. I wonder why they added that "placeholder" glyph instead of a real 3-em dash.

Anyhow, with the patch here we should prefer Segoe UI (which has the "real" glyph) over the Symbol face, so we should be OK.

Comment 17

[Thorin [:thorin]]

https://learn.microsoft.com/en-us/typography/fonts/windows_11_font_list etc

• win11 says 6.23 - I have 6.24
• win10 says 6.23
• win 8.1 says 6.09 ... no, wait ... we don't support that any more so no-one cares :)

IANAE on windows updates - IDK if OS updates always include all possible font updates - would be wishful thinking that 1. MS ship everyone the same font versions across all platforms and 2 users update. One thing that I have been working on is unicode differences (in windows and mac) - i.e font version changes, to exploit that in fingerprints

Comment 18

[Jonathan Kew [:jfkthame]]

According to https://eng.fontke.com/font/25396382/, Segoe UI Symbol v6.23 supports 51 out of 128 characters in the Supplemental Punctuation block, while https://eng.fontke.com/font/244363513/ says that v6.24 supports 94 of them. Various other Unicode blocks got updates as well: overall, it looks like there are around 270 more codepoints supported in the newer version.

I don't know exactly what Windows update (or other package) may have delivered the updated Segoe UI Symbol version. But anyhow, yes, this is the sort of font update that I think could, in principle, be used in fingerprinting.