1513067 - U+22C5 DOT OPERATOR renders a missing-character icon (gray rectangle) on Pixel 2 Android 9/Pi

Status: RESOLVED WORKSFORME

(Firefox for Android Graveyard :: General, defect, P3)

Description

[Daniel Holbert [:dholbert]]

STR:
 1. Visit https://www.google.com/search?q=restaurant+marrakesh+epcot&ie=utf-8&oe=utf-8&client=firefox-b-1 in Firefox on Android. (I'm using nightly 65 on a Pixel 2 running Android Pi, which I think is version 9.)

 2. Scroll down to look for the "Open" / "Closed" line.

ACTUAL RESULTS:
There's a weird gray block between "Open" and "closes 9:30pm" (or whatever it shows depending on the time of day when you view it).

EXPECTED RESULTS:
This block is expected to be a small dot. It is U+22C5 DOT OPERATOR.

Smaller / more direct testcase: https://jsfiddle.net/u185kqej/

I initially filed this as https://github.com/webcompat/web-bugs/issues/22393#issuecomment-445691699 from my phone, while I was at Epcot. But it seems to be a Firefox bug as noted there.

Quoting jfkthame:
=========
If there's a font on the device that supports U+22C5, then Firefox ought to find it in the fallback search. So I'm guessing the problem here is that no available font supports it. To confirm that, we'd need to pull a copy of all the installed fonts and check their character maps.

Assuming that's correct, how does Chrome display it, then? A couple of possibilities: do they bundle any additional fonts with the browser (like we do for our emoji font, for example)? If so, they could have an extended version of Roboto or some other font that supports this symbol, even though there isn't one installed on the device. Alternatively, they could be doing some kind of character-level fallback for unavailable characters, and displaying U+22C5 as U+00B7 MIDDLE DOT, which is widely supported in fonts.
=========

Comment 1

[Jonathan Kew [:jfkthame]]

So that we know more clearly what we're dealing with, could you pull a copy of the /system/fonts directory from your device and check whether there is in fact any installed font that supports U+22C5? (If you don't have tools to check this readily, feel free to post an archive of the fonts dir and I'll take a look.) Thanks.

Comment 2

[Andrei Bodea[:andrei]]

Hello,

I was able to reproduce this issue on the latest Nightly build(65.0a1) using a Google Pixel 3 XL with Android P(9).
I downloaded the /system/fonts directory from my device and you can find and download it from here: https://goo.gl/NVoXNT
Also, I tried to reproduce this issue on Google Chrome but everything was correctly displayed see the photo comparison  here: https://prnt.sc/ltk59c

Thanks,
Andrei

Comment 3

[Jonathan Kew [:jfkthame]]

Thanks. OK, I looked at these fonts, and confirmed that there *is* a font that supports U+22C5: specifically, NotoSansSymbols-Regular-Subsetted.ttf includes this codepoint.

So the question is why Firefox fails to find and use this font as a fallback, when the main font being used doesn't have the character.

If we explicitly request the Noto Sans Symbols family in CSS, as in https://jsfiddle.net/at8nmusv/, does the dot render then, or do we still get a missing-glyph square?

Comment 4

[Andrei Bodea[:andrei]]

Hello Jonathan,

I checked the https://jsfiddle.net/at8nmusv/ with the Google Pixel 3 XL - Android P (the device from which I've exported the fonts above) and the dot was displayed.

Thanks,
Andrei

Comment 5

[Jonathan Kew [:jfkthame]]

Interesting. So we *can* use the Noto Sans Symbols font (I was wondering if maybe Firefox was failing to load it because of something odd about the font file). The question, then, is why the global font fallback code doesn't choose it.

One thing that might help is to explicitly list this font in the Android "common fallbacks" code. I've pushed a try build that does this, at https://treeherder.mozilla.org/#/jobs?repo=try&revision=ac3e8c9f992c11c8f49643ff98abf0d4379c5250. When the build is ready, please try it and confirm whether this resolves the problem on the original site and on dholbert's testcase. Thanks.

Comment 6

[Daniel Holbert [:dholbert]]

I tried the comment 5 build, and unfortunately it does not fix the issue. (Tested the URL & jsfiddle testcase from comment 0.)

The same gray block still shows up, instead of a dot.

Comment 7

[Daniel Holbert [:dholbert]]

(And for good measure: I tested the jsfiddle from comment 4, with the font explicitly in the CSS, and I do see the dot there.)

Comment 8

[Kevin Brosnan [Ex-Mozilla]]

For another data point I can see the dot character on a Pixel 2 XL and a Pixel 3 using v65 and v63.

Comment 9

[Jonathan Kew [:jfkthame]]

Odd; I thought the comment 5 hack was likely to make it appear. It sure looks like something in the font-selection/fallback code isn't behaving correctly, though at this point I'm not sure quite where the problem lies. I guess I'll have to try to set up a device or emulator to reproduce and debug.... :\

Comment 10

[Daniel Holbert [:dholbert]]

(In reply to Kevin Brosnan [:kbrosnan] from comment #8)
> For another data point I can see the dot character on a Pixel 2 XL
> and a Pixel 3 using v65 and v63.

Confirmed! I just got a new Pixel 3, and I *cannot* reproduce the issue in Nightly there.
(Same version of Android [& same patch-level] as my Pixel 2. Both devices running latest Nightly build, both of them just installed/reinstalled fresh today.)

So, we have the following data on affected/unaffected devices so far:

 Pixel 2:    AFFECTED (dholbert)
 Pixel 2 XL: Unaffected (kbrosnan)
 Pixel 3:    Unaffected (kbrosnan, dholbert)
 Pixel 3 XL: AFFECTED (Andrei)

Comment 11

[Karl Dubost💡 :karlcow]

Google Page. https://www.google.com/search?q=restaurant+marrakesh+epcot&ie=utf-8&oe=utf-8&client=firefox-b-1
Pixel 2: AFFECTED Android 9  Build Number PQ1A.181105.017.A1
Pixel 2: AFFECTED Android 9  Build Number PQ1A.181205.002 (updated today)

https://jsfiddle.net/at8nmusv/
Pixel 2: Android 9  Build Number PQ1A.181205.002 (updated today)
shows the dot in the rendered part of the jsfiddle, but shows the grey square in the HTML code section (while Chrome shows the dot at the two places).

Comment 12

[Daniel Holbert [:dholbert]]

My Pixel 3 with Nightly now behaves exactly as karl describes in comment 11.

The Google search results page is AFFECTED, and the jsfiddle is AFFECTED in the "HTML code section" but not in the rendered results section.

Also, I ran into another instance of what I think is the same problem (but with different UTF characters):
https://github.com/webcompat/web-bugs/issues/23526

I created this reduced testcase with those characters ("U+2630 TRIGRAM FOR HEAVEN" and "U+25B8 BLACK RIGHT-POINTING SMALL TRIANGLE"): https://jsfiddle.net/htx4Lkj9/

(And in this new case, both the HTML area as well as the rendered-result area shows the grey squares, but that's just because no font is explicitly specified for the rendered area, unlike the previous jsfiddle referenced in comment 11.)

Comment 13

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Comment 14

[Daniel Holbert [:dholbert]]

On my Pixel 3, all three symbols show up in the bottom half of testcase 1 (i.e. when the Noto Sans Symbols font is specified), but not in the top half (when no font is specified).

Comment 15

[Kevin Brosnan [Ex-Mozilla]]

dholbert would you check against Nightly or Beta. Bug 1509067 may have fixed this.

Comment 16

[Daniel Holbert [:dholbert]]

As of today, I can't reproduce now under any configuration that I've tested, including Firefox 65.0.1 on the same Pixel 2 device (still on Android 9) from comment 0. (I also tested Nightly 67 from 2019-03-15 on that device, and Firefox Nightly 68 on my newer Pixel 3 which has Android 10 "Q". Couldn't repro in any of these scenarios.)

I tried both links from comment 0 (the google link and the jsfiddle), as well as the attached testcase.

So, I'd consider this WORKSFORME -- I can't repro anymore, though there's a bit of mysteriousness because I'm seeing expected behavior from versions that don't have the hypothetical fix. (Maybe I got a system update that included some font changes, and that fixed this at a lower font-matching level?)

Feel free to upgrade to FIXED if we get stronger confirmation than what I'm able to provide (particularly if someone finds a configuration where they can still repro).

Comment 17

[Jonathan Kew [:jfkthame]]

I think it's highly likely this was fixed by bug 1509067, even if it's now proving difficult to repro with older builds.

I'm not totally sure without digging back into code, but it's possible that before bug 1509067, we picked one of the subset faces of the Symbols font more-or-less at random (probably dependent on the order the files were found when iterating over the fonts directory). So then whether we found the required character or not might vary between apparently very similar devices, or even on the same device with the same fonts if the (indeterminate) ordering of the fonts (subsets) somehow changed.

Since bug 1509067, we explicitly check all the subset faces in a case like this, so should always find the character if it exists anywhere.