User Agent: Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0 Cyberfox/52.0 Build ID: 20170223104952 Steps to reproduce: Open Preview Windows and look icon "last site" "first site". Not icons.

It's due to bug 334598 and bug 1292498, see the icon changes in my screenshot.

Yikes, that's scary. Too late for Fx52 as we're releasing it on Tuesday, but would be great to fix this for 53 (and possibly backport to ESR52 as well).

Can you please get a regression range with acceleration disabled? Bug 1292498 will only have changed which configuration you get, it shouldn't have changed rendering at all.

With HWA disabled, I got Bug 1007702 instead of Bug 1292498. https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=024e7dc7a219e3f276bc2245746bbad67a574ea9&tochange=209072396aa5ab5c5a0a28109a980dbbcd884922

Ok, so I guess skia+printing is failing to render those characters correctly.

Lee, can you take a look please?

Not pretty.... tracking for 53 and 54.

So, the investigation so far: When Cairo is selected as the content backend, we use the GDI platform font list. When Skia is used, we use the dwrite platform font list. In talking with Jonathan Kew, he was not able to reproduce this issue at all under any combination of prefs under Windows 10. I, however, was able to readily reproduce this on Windows 7 via any combination of prefs that resulted in dwrite being the platform font list selected (so Skia without HWA, or D2D with HWA). It is worth noting that the reporter of this bug is also on Windows 7. Jonathan had the following relevant comments from IRC on what he thought was the reason: <jfkthame> my guess is that on win7 the only font that supports this character will turn out to be a bitmap font that dwrite doesn't support <jfkthame> this is not too surprising, actually, given that U+23EE was introduced in Unicode 6.0, released October 2010 -- but Windows 7 shipped about a year before that <jfkthame> therefore, a product that supports Win7 probably shouldn't assume availability of U+23EE (and similar characters), it should provide its own font if it wants to use them <jfkthame> http://www.fileformat.info/info/unicode/char/23ee/index.htm <jfkthame> https://en.wikipedia.org/wiki/Windows_7 I am still looking to see if there is a workaround, but essentially, it looks like it is not safe to use this character in our UI on Windows 7 in the way we have done.

Yet further investigation has found that the problem in some part stems from gfxDWriteFontList::GlobalFontFallback (https://dxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxDWriteFontList.cpp?q=gfxDWriteFontList%3A%3AGlobalFontFallback&redirect_type=single#1386). This skips the code that might otherwise check if EmojiOne Mozilla supports the characters in question (#x23ee and #x23ed). That code was introduced in bug 705594. Not sure exactly why that code decides to skip the fallbacks, but Jonathan Kew might know more. Another possible code workaround that seemed to work in local testing is to add EmojiOne Mozilla as a fallback for the symbol ranges here: https://dxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxWindowsPlatform.cpp?q=gfxWindowsPlatform%3A%3AGetCommonFallbackFonts&redirect_type=single#765 That allowed it to find the #x23ee and #x23ed symbols from EmojiOne Mozilla when Segoe UI Symbol failed to provide them. Maybe an even simpler UI workaround that requires no code changes would be to use these characters instead that Segoe UI Symbol provides in Windows 7 SP1 (#x23ea and #x23e9): http://www.fileformat.info/info/unicode/char/23ea/index.htm http://www.fileformat.info/info/unicode/char/23e9/index.htm Would like input from Jonathan and/or Dao on what the best option here might be to proceed with...

(In reply to Lee Salzman [:lsalzman] from comment #9) > Maybe an even simpler UI workaround that requires no code changes would be > to use these characters instead that Segoe UI Symbol provides in Windows 7 > SP1 (#x23ea and #x23e9): > http://www.fileformat.info/info/unicode/char/23ea/index.htm > http://www.fileformat.info/info/unicode/char/23e9/index.htm These have a different meaning that isn't quite fit here, so I'd prefer if we didn't have to resort to that.

(In reply to Lee Salzman [:lsalzman] from comment #9) > Yet further investigation has found that the problem in some part stems from > gfxDWriteFontList::GlobalFontFallback > (https://dxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxDWriteFontList. > cpp?q=gfxDWriteFontList%3A%3AGlobalFontFallback&redirect_type=single#1386). > This skips the code that might otherwise check if EmojiOne Mozilla supports > the characters in question (#x23ee and #x23ed). That code was introduced in > bug 705594. Not sure exactly why that code decides to skip the fallbacks, > but Jonathan Kew might know more. The work in bug 705594 was primarily done to avoid hitting a potentially (very) slow DirectWrite code path, leading to multi-second delays the first time font fallback is hit. (I think this has been fixed on newer Windows releases, but not sure of the exact status.) Looking into those characters a bit more, I'm inclined to suggest we should avoid using them like this. We _could_ arrange to render them from the EmojiOne Mozilla font, but I don't think that's a good solution. It would result in color emoji-style glyphs that IMO would be quite out of place in this UI; and it would mean they'd fail to respond to a theme that attempts to change the color, for example. Given that these symbols are not widely supported, my suggestion would be to provide the desired icons as SVG images, and avoid being dependent on the whims of available fonts.

(In reply to Dão Gottwald [:dao] from comment #10) > (In reply to Lee Salzman [:lsalzman] from comment #9) > > Maybe an even simpler UI workaround that requires no code changes would be > > to use these characters instead that Segoe UI Symbol provides in Windows 7 > > SP1 (#x23ea and #x23e9): > > http://www.fileformat.info/info/unicode/char/23ea/index.htm > > http://www.fileformat.info/info/unicode/char/23e9/index.htm > > These have a different meaning that isn't quite fit here, so I'd prefer if > we didn't have to resort to that. So given that our entire population of Windows 7 users is seeing missing glyph boxes right now, anything is an upgrade over that. As Jonathan Kew also pointed out, currently any code workaround means that the existing glyphs, even if rendered, are mixing EmojiOne Mozilla, so on the one hand they see cartoony aqua-colored double-arrows, and flat black single arrows from Segoe UI Symbol, with no real consistency. I can also confirm that it appears this way on Linux too. No idea about Mac. In general, this does not look so nice even when those arrows show up as on Linux, or on Windows 7 with my local code hacks in place. So I support Jonathan's assessment that we replace these with something that will look decent on all platforms rather than mix inconsistently-appearing symbols from wildly different fonts.

(In reply to Lee Salzman [:lsalzman] from comment #12) > As Jonathan Kew also pointed out, currently any code workaround means that > the existing glyphs, even if rendered, are mixing EmojiOne Mozilla, so on > the one hand they see cartoony aqua-colored double-arrows, and flat black > single arrows from Segoe UI Symbol, with no real consistency. This is getting off-topic, but note that Web content will run into the exact same problem. We should have considered this when bundling EmojiOne. Obviously there's no font that will look good regardless of the context, but something more neutral and less cartoony would have been nice. > I can also > confirm that it appears this way on Linux too. No idea about Mac. In > general, this does not look so nice even when those arrows show up as on > Linux, or on Windows 7 with my local code hacks in place. WFM on Ubuntu.

Given that we're considering this for 52ESR, and 53 beta just started, having a patch earlier, rather than later, would be beneficial.

Comment on attachment 8845894 [details] Bug 1343330 - Use fast-forward and fast-rewind characters instead of skip-to-end and skip-to-start on Windows 7. https://reviewboard.mozilla.org/r/119022/#review121586 Note: here on OS X Yosemite these characters don't exist either. It's not a direct problem on Mac since print preview is not used here, but should we just use the more common character always for the sake of simplicity? Or do you think the alternative one looks significantly better?

Given that even when the ⏭ and ⏮ characters are present, there's a strong possibility they will appear in an "emoji style" that may not fit in at all well with the rest of the UI, I don't think they're a good choice for this on any platform. Either simple SVG images or a tiny custom font, which could be loaded as a data: URL right in the stylesheet, to avoid asynchronous font-loading issues, would be a safer choice, and would allow the symbols to be colored as expected by theme styles (which won't work for symbols that get rendered from a color-emoji font).

(In reply to Jonathan Kew (:jfkthame) from comment #17) > Given that even when the ⏭ and ⏮ characters are present, there's a strong > possibility they will appear in an "emoji style" that may not fit in at all > well with the rest of the UI, I don't think they're a good choice for this > on any platform. WFM on Windows 10 and Ubuntu. I can file a followup, but in the meantime I'll land this patch since it should be a net improvement and safe for uplifting.

Pushed by dgottwald@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/8cd4168dbb04 Use fast-forward and fast-rewind characters instead of skip-to-end and skip-to-start on Windows 7. r=Felipe

backed out for eslint failure https://treeherder.mozilla.org/logviewer.html#?job_id=83674713&repo=autoland

Backout by cbook@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/9a26ed658fdc Backed out changeset 8cd4168dbb04 for eslint failure

Pushed by dgottwald@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/dc5d8fd7a1e0 Use fast-forward and fast-rewind characters instead of skip-to-end and skip-to-start on Windows 7. r=Felipe

(In reply to Dão Gottwald [::dao] from comment #18) > (In reply to Jonathan Kew (:jfkthame) from comment #17) > > Given that even when the ⏭ and ⏮ characters are present, there's a strong > > possibility they will appear in an "emoji style" that may not fit in at all > > well with the rest of the UI, I don't think they're a good choice for this > > on any platform. > > WFM on Windows 10 and Ubuntu. I can file a followup, but in the meantime > I'll land this patch since it should be a net improvement and safe for > uplifting. filed bug 1347126

Comment on attachment 8845894 [details] Bug 1343330 - Use fast-forward and fast-rewind characters instead of skip-to-end and skip-to-start on Windows 7. Approval Request Comment [Feature/Bug causing the regression]: bug 334598 / bug 1292498 [User impact if declined]: see comment 0 [Is this code covered by automated tests?]: no [Has the fix been verified in Nightly?]: not yet [Needs manual test from QE? If yes, steps to reproduce]: yes, STR in comment 0 [List of other uplifts needed for the feature/fix]: / [Is the change risky?]: no [Why is the change risky/not risky?]: This just makes us use two simpler symbols on Windows 7. Can hardly make things any worse. [String changes made/needed]: /

Hi Brindusa, could you help find someone to verify if this issue was fixed as expected on a latest Nightly build based on comment #0? Thanks!

On my Win 7 64b, it's fixed with the latest Nightly 32b.

(In reply to Loic from comment #28) > Created attachment 8847626 [details] > screenshot-verified-fixed.png > > On my Win 7 64b, it's fixed with the latest Nightly 32b. Just FTR, note that while this screenshot shows we no longer get hexboxes, so this immediate bug is fixed, it also illustrates the hazard of using not-very-well-supported characters here: the single- and double-arrow symbols are quite badly mismatched, probably because they're being drawn from different fonts (depending what font fallback happens to find). Bug 1347126 will allow us to guarantee a consistent design for the set of buttons.

Tested on the latest Nightly 55.0a1(2017-03-15) with Windows 7 x64 and I can confirm the fix.

Comment on attachment 8845894 [details] Bug 1343330 - Use fast-forward and fast-rewind characters instead of skip-to-end and skip-to-start on Windows 7. Fix a print preview regression and was verified. Beta53+ & Aurora54+.

I can confirm this issue is fixed, I verified using Firefox 53.0b3, 54.0a2 on Win 7 x64 .

Comment on attachment 8845894 [details] Bug 1343330 - Use fast-forward and fast-rewind characters instead of skip-to-end and skip-to-start on Windows 7. fix print preview regression, for 52.1.0esr

Timea, could you please take a look at this on 52.1esr as well?

I can confirm this issue is fixed, I verified using Firefox 52.1esr on Win 7 x64 .