Emoji disappear/become square boxes on https://emojipedia.org/smiling-face-with-hearts/
Categories
(Core :: Layout: Text and Fonts, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox80 | --- | verified |
People
(Reporter: mayankleoboy1, Assigned: jfkthame)
References
()
Details
Attachments
(10 files)
37.37 KB,
image/png
|
Details | |
20.25 KB,
text/plain
|
Details | |
137.06 KB,
image/png
|
Details | |
8.39 KB,
image/png
|
Details | |
356 bytes,
text/html
|
Details | |
2.48 KB,
text/html
|
Details | |
394.35 KB,
video/mp4
|
Details | |
1.34 MB,
video/mp4
|
Details | |
660.45 KB,
application/octet-stream
|
Details | |
47 bytes,
text/x-phabricator-request
|
Details | Review |
- New profile
- Enable gfx.e10s.font-list.shared
- Restarrt browser
- GO to https://emojipedia.org/smiling-face-with-hearts/
- Close the browser. Restart the browser
- Click on "Restore previous session"
ER: All emojis are visible
AR: randomly some of the emojis are replaced by a blank rectangle
STR2:
1.Go to https://emojipedia.org/emoji/
2. Close the browser. Restart the browser
3. Click on "Restore previous session"
Randomly some of the emojis will be replaced by a blank rectangle.
Reporter | ||
Comment 1•5 years ago
|
||
Reporter | ||
Updated•5 years ago
|
Comment 2•5 years ago
|
||
P3 as this is with the shared font list only. Thanks for filing Mayank :)
Assignee | ||
Comment 3•5 years ago
|
||
I've tried to reproduce this a bunch of times on my Windows laptop with the shared font list enabled, but never seen the problem. On restoring the session, the emojis are consistently displaying fine for me.
One thing I see in the about:support data that I suppose might possibly be a factor is the presence of "Kaspersky Free" antivirus software. Mayank, can you try disabling this and see if it affects the behavior at all?
Reporter | ||
Comment 4•5 years ago
|
||
I disabled Kasperky, and it had no effect. I also tried deleting the HTTP cache, but even that had no effect.
Initially when i saw this bug, it reproduced every time I just opened the page. But then after a few more refreshes, it reproduced only after a restart-and-session-restore. So not really sure whats happening.
Also, the emojis disappear on other sites as well, like the phabricator review pages.
Assignee | ||
Comment 5•5 years ago
|
||
I'm still not sure what's going wrong here, and haven't successfully reproduced the problem locally. One thing that might help give a clue: could you try disabling WebRender (I guess setting gfx.webrender.force-disabled
to true and restarting the browser should do it), and see if the problem still occurs at all? It kinda looks to me like the font may be failing only in the rendering process, not in the content process.
Reporter | ||
Comment 6•5 years ago
•
|
||
I tried with WR disabled, and can still repro the bug
I would be happy to run any diagnostic/logging build and share the output with you.
Edit: did you try the STR 2 ?
0. Enable shared font cache
1.Go to https://emojipedia.org/emoji/
2. Close the browser. Restart the browser
3. Click on "Restore previous session"
Reporter | ||
Comment 7•5 years ago
|
||
Other peculiar things . URL :https://emojipedia.org/emoji/%F0%9F%A4%A9/
If you see the attached image, the emoji renders correctly on the page.
However, if I select the emoji, and right click to search for it on google, the text next to "Search Google for" has the emoji as blank on the right-click popup
The page icon on the tab also has the blank emoji.
Reporter | ||
Comment 8•5 years ago
|
||
Reporter | ||
Comment 9•5 years ago
|
||
Reporter | ||
Comment 10•5 years ago
|
||
more peculiarity : IF you hover your mouse over the emojipedia link I put in the above comment, the URL popup generated on the bottom left of the screen also shows a blank emoji with shared font cache.
Reporter | ||
Comment 11•5 years ago
•
|
||
You can also try to load this bugzilla link : https://bugzilla.mozilla.org/show_bug.cgi?id=1492605#c0
This shows rows and rows of blank squares of i enable shared font cache.
FWIW, the emoji font is Sego UI Emoji
Assignee | ||
Comment 12•5 years ago
|
||
I'm still unable to reproduce any of the issues described, on my Win10 machine with the shared font list enabled; the emoji font stubbornly insists on working just fine for me in all these scenarios.
Puzzling.... clearly something is going wrong on Mayank's system, but I have no idea what. :(
Reporter | ||
Comment 13•5 years ago
|
||
FWIW, I have the Release Preview of Win10 Version 2004. Using mozregression, I tried a build from October2019 with shared font enabled, and that also had the same issue with emojis.
If you have a spare system with Windows10, can you try installing the Release Preview, and then testing this?
Comment 14•5 years ago
|
||
The severity field is not set for this bug.
:dholbert, could you have a look please?
For more information, please visit auto_nag documentation.
Assignee | ||
Comment 15•5 years ago
|
||
(In reply to Mayank Bansal from comment #13)
FWIW, I have the Release Preview of Win10 Version 2004. Using mozregression, I tried a build from October2019 with shared font enabled, and that also had the same issue with emojis.
I'm on a current Windows Insider build, it describes itself as Windows 10 Pro, version 2004, OS build 19628.1 (but there have been various updates since the first time I tried to reproduce this, and behavior hasn't changed for me).
Blinky, I know you have done a lot of testing on Windows with gfx.e10s.font-list.shared enabled; are you able to reproduce this issue at all?
Comment 16•5 years ago
|
||
I can't reproduce either, FWIW. Win10 19041.264.
Reporter | ||
Comment 17•5 years ago
•
|
||
I opened nightly in Safe Mode, and could see the emojis rendering correctly. Does starting in safe mode disable shared font caching?
Alternately, I didsbled HW acceleration, and could still see the empty blocks... So the culprit could be whatever gets disabled in safe mode, but doesnt disable with HWA disabled
Assignee | ||
Comment 18•5 years ago
|
||
Yes, safe mode will disable the shared font list, because that's a non-default preference setting.
(You can check whether it's being used at runtime by looking at the about:memory report, and filtering for font-list
. If the shared list is active, there'll be an entry for font-list-shmem
near the end of the Main Process section. If it's not active, this will be absent, and the per-process figures for gfx/font-list
will be substantially larger instead.)
Updated•5 years ago
|
Comment 19•5 years ago
|
||
(In reply to Jonathan Kew (:jfkthame) from comment #15)
Blinky, I know you have done a lot of testing on Windows with gfx.e10s.font-list.shared enabled; are you able to reproduce this issue at all?
I can not reproduce this bug on Win10 and Win7.
Reporter | ||
Comment 20•5 years ago
|
||
This file displays correctly with shared font cache
Reporter | ||
Comment 21•5 years ago
|
||
This file does not display correctly with shared font cache.
Reporter | ||
Comment 22•5 years ago
•
|
||
Hi🔥🔥🔥☠☠☠☠
@Jfkthame : The 3 "fire" emojis display correctly. The 4 "skull and crossbones" appear as square boxes
Could it be something related to ANSI/UTF encoding and region/language setting in windows?
Reporter | ||
Updated•5 years ago
|
Assignee | ||
Comment 23•5 years ago
|
||
(In reply to Mayank Bansal from comment #22)
Hi🔥🔥🔥☠☠☠☠
@Jfkthame : The 3 "fire" emojis display correctly. The 4 "skull and crossbones" appear as square boxes
Could it be something related to ANSI/UTF encoding and region/language setting in windows?
It's not an encoding issue, or none of them would appear.
If you right-click on the text and choose Inspect Element, and then check in the inspector's Fonts panel on the right, what font (or fonts) does it report is being used here on your system?
Reporter | ||
Comment 24•5 years ago
•
|
||
fonts are "Segoe UI Emoji" in the text in comment#22 . All the emojis (both fire and skull are "Segoe UI Emoji")
Here is another strange thing: If I delete the 3 "fire" emojis, my text looks like : Hi☠☠☠☠ it displays correctly! When i checked in the font inspector, the font had automagically changed to "Segoe UI Symbol"
Theory: presence of "Segoe UI Emoji" and "Segoe UI Symbol" in the same word causes the text in "Segoe UI Symbol" to be detected as "Segoe UI Emoji", and rendered incorrectly.
I will attach a video to show what i mean
Reporter | ||
Comment 25•5 years ago
|
||
Reporter | ||
Updated•5 years ago
|
Reporter | ||
Comment 26•5 years ago
|
||
Assignee | ||
Comment 27•5 years ago
|
||
The font "magically" changing is a known behavior -- not really a bug, just a feature of how fallback works. The Skull & Crossbones (U+2620) is available in both Segoe UI Symbol (as a monochrome glyph) and in Segoe UI Emoji (a "color" glyph, though in this case it's not very colorful, just some gray fill). Font fallback (which comes into play because the font-family property just specifies "FiraGO", sans-serif
, neither of which support these characters) picks Segoe UI Symbol for it.
However, if there's a Fire emoji before it, that's not supported by Segoe UI Symbol, only by the Emoji font. So fallback must pick that. And one of the things Gecko's font fallback code does is that it tries to re-use the same font rather than constantly switching, and so having chosen the Emoji font for the Fire character, it then uses it for Skull & Crossbones as well.
So... this is understood, at least.
I'm still not clear why the Skull & Crossbones fails to render when we try to use Segoe UI Emoji for it, though. Other people don't seem to be able to reproduce the same failure, which is weird.
(Out of curiosity, if you put the skulls first and then the fire, as ☠☠☠☠🔥🔥🔥, do they all work?)
Reporter | ||
Comment 28•5 years ago
|
||
(In reply to Jonathan Kew (:jfkthame) from comment #27)
(Out of curiosity, if you put the skulls first and then the fire, as ☠☠☠☠🔥🔥🔥, do they all work?)
They all work correctly
Assignee | ||
Comment 29•5 years ago
|
||
OK, I expected they would but it's nice to have that confirmed!
Reporter | ||
Comment 30•5 years ago
•
|
||
these are the segoe symbol and segoe emoji font present on my Fonts directory... Could it be that they have become corrupted on my system?
Edit: if you can share with me the two ttf files from your system, i can try installing from those and see if the issue still persists
Assignee | ||
Comment 31•5 years ago
|
||
(In reply to Mayank Bansal from comment #30)
these are the segoe symbol and segoe emoji font present on my Fonts directory... Could it be that they have become corrupted on my system?
Those files exactly match what I have on my Win10 machine, so it's nothing like that. I still haven't been able to reproduce the issue here, though.
(BTW, I'm going to mark your attachment as private, as on principle I don't think we should be posting these in a publicly-accessible place.)
Reporter | ||
Comment 32•5 years ago
•
|
||
Assignee | ||
Comment 33•5 years ago
|
||
Is it possible you have an older copy of the Segoe UI Emoji somewhere (in addition to the version that comes with current Win10)? I think that could help explain the strange issues you have been seeing here.
Try looking in the c:\windows\fonts\ directory using a Command Prompt window (I don't think you can trust Explorer to show the actual contents of the directory) with a command like dir c:\windows\fonts\seg*
and see what shows up... or do you have some kind of font management software that enables fonts separately from installing them in the standard Windows location?
Reporter | ||
Comment 34•5 years ago
|
||
07-12-2019 02.38 PM 261,872 segmdl2.ttf
07-12-2019 02.38 PM 168,404 segoepr.ttf
07-12-2019 02.38 PM 167,800 segoeprb.ttf
07-12-2019 02.38 PM 596,948 segoesc.ttf
07-12-2019 02.38 PM 581,252 segoescb.ttf
07-12-2019 02.38 PM 955,804 segoeui.ttf
07-12-2019 02.38 PM 951,724 segoeuib.ttf
07-12-2019 02.38 PM 529,712 segoeuii.ttf
07-12-2019 02.38 PM 913,712 segoeuil.ttf
07-12-2019 02.38 PM 854,140 segoeuisl.ttf
07-12-2019 02.38 PM 541,468 segoeuiz.ttf
07-12-2019 02.38 PM 324,260 seguibl.ttf
07-12-2019 02.38 PM 356,008 seguibli.ttf
07-12-2019 02.38 PM 2,072,388 seguiemj.ttf
07-12-2019 02.38 PM 1,400,724 seguihis.ttf
07-12-2019 02.38 PM 459,940 seguili.ttf
07-12-2019 02.38 PM 971,080 seguisb.ttf
07-12-2019 02.38 PM 457,892 seguisbi.ttf
07-12-2019 02.38 PM 467,180 seguisli.ttf
07-12-2019 02.38 PM 2,454,728 seguisym.ttf
this is what turns up if i run the command dir c:\windows\fonts\seg* in an admin cmd prompt.
I do not have any font management softwareon my computer.
I am happy to run any debug build or log any thing that would help to solve this bug.
Reporter | ||
Comment 35•5 years ago
|
||
The bugzilla testcase here : https://bugzilla.mozilla.org/attachment.cgi?id=9159611 also shows the same issue. The flag emoji is rendered as a square.
Reporter | ||
Comment 36•5 years ago
|
||
OK, mystery solved. I had two segoe Emoji fonts installed on my system.
One was in c:\windows\font
the other was in my local profile.
Apparently, Windows was using the font installed in my local profile.
So, I uninstalled the font in my local profile, deleted the fontcache.dat file, and restarted the fontcache service. All the examples work fine for me now.
I will attach the emoji.ttf file, if you are interested in looking at it.
Reporter | ||
Comment 37•5 years ago
|
||
Assignee | ||
Comment 38•5 years ago
|
||
Aha! Yes, that's a (much) older version of the font -- probably dates back to Windows 8 or something like that.
When you say
the other was in my local profile.
where exactly do you mean -- somewhere within the Firefox profile directory, or what? I'd like to understand better how this resulted in the broken behavior...
Reporter | ||
Comment 39•5 years ago
|
||
The font was in :
C:\Users\Mayank\AppData\Local\Microsoft\Windows\Fonts
I have no idea how they got here. I noticed them when i went to desktop->right click->personalize->font , and searched for "emoj". I saw two different segoemoji font. The first was in the path mentioned above , and the second was in Windows/fonts folder.
Assignee | ||
Comment 40•5 years ago
|
||
OK, thanks; that may be the clue I need to reproduce this with a similar setup, and figure out why the two versions are getting confused (and why it only happens with the shared-fontlist pref enabled).
Reporter | ||
Comment 41•5 years ago
•
|
||
If you download the emoji font attachment to your system, right click on it, and "install" it but NOT "Install for all users" , the font should get installed your local windows profile. Then you should be able to repro this bug. (No need to delete fontcache.dat or restart the font caching service)
I also checked, and the fonts installed on the local windows directory take precedence over the ones installed "globally" . So maybe by enabling the shared font cache pref, nightly is picking up the locally installed fonts, and picking up the globally installed font otherwise.
Assignee | ||
Comment 42•5 years ago
|
||
Right, that works to reproduce the problem.
Firefox actually finds both of the fonts, and should be able to pull glyphs from both as needed, but for some reason this isn't working properly when the shared font-list is enabled. It does actually find the characters in the newer (globally-installed) font when it's doing the text layout (otherwise you'd be seeing hexboxes with the Unicode value); but then it fails to use the right face when it comes to render the glyphs.
My debug build on Windows is being troublesome at the moment, but I should be able to track down what's happening here...
Assignee | ||
Comment 43•5 years ago
|
||
At last, I think I know what's going on. To confirm my suspicions, could you please try setting gfx.font_rendering.directwrite.use_gdi_table_loading
to false
in about:config (its default value should be true
), and then restart the browser and see if you can still reproduce this issue. (I believe that will prevent it happening.) Thanks!
Assignee | ||
Comment 44•5 years ago
|
||
So the problem here occurs because there are two Segoe UI Emoji faces installed that have exactly the same style properties, but different character sets. In general, DirectWrite handles this fine; the IDWriteFontFamily will expose both faces and both can be accessed. And Firefox handles this as well: if multiple faces in a family match the requested style properties, it will check them all for the characters needed.
The problem arises because of the optimization that was implemented in gfxDWriteFontEntry to read font tables via GDI calls if we have not yet instantiated an IDWriteFontFace object (which can be time-consuming). When the shared font list is enabled, we end up wanting to check the character coverage of the face prior to instantiating the dwrite interfaces, so we go via the GDI-based code path in gfxDWriteFontEntry::CopyFontTable.
Usually that works OK. But the way it works is by setting up a GDI LOGFONTW record to select the font, and that record cannot distinguish between the two identically-named and -styled emoji faces here. So it's a coin-toss as to which of them GDI will end up using to return the font table. And what's happening here, then, is that we get the cmap table from the new font when we're trying to query the old face, so we believe that it supports the new emoji characters, and proceed to use it for codepoints that it does not in fact cover.
It's tempting to just rip out the GDI table access codepath altogether, but that might lead to some perf regressions, so I think a more conservative way forward for now will be to ensure that we only use that path for "simple" font families (i.e. those with no more than four faces, which fit into the four "standard" style positions of Regular, Bold, Italic, and BoldItalic). We already detect such families so that we can use a simplified style-matching algorithm; we can also use this as a signal that it is safe to use the GDI table access path. For families with more styles, or with multiple faces that share the same style, this path is unsafe because the GDI LOGFONTW cannot reliably distinguish the faces and ensure we access the intended resource.
Reporter | ||
Comment 45•5 years ago
|
||
(In reply to Jonathan Kew (:jfkthame) from comment #43)
At last, I think I know what's going on. To confirm my suspicions, could you please try setting
gfx.font_rendering.directwrite.use_gdi_table_loading
tofalse
in about:config (its default value should betrue
), and then restart the browser and see if you can still reproduce this issue. (I believe that will prevent it happening.) Thanks!
gfx.font_rendering.directwrite.use_gdi_table_loading = False fixed the issue (all fonts display correctly)
Assignee | ||
Comment 46•5 years ago
|
||
Updated•5 years ago
|
Comment 47•5 years ago
|
||
Comment 48•5 years ago
|
||
bugherder |
Assignee | ||
Updated•5 years ago
|
Updated•5 years ago
|
Comment 49•5 years ago
|
||
I’ve reproduced this issue using information from comments 36-41 with Fx 77.0a1 (2020-04-16) on Windows 10
The issue is verified fixed with Fx 81.0a1 (2020-08-06) and Fx 80.0b5 on Windows 10.
Description
•