1514112 - cairo and font smoothing in Firefox 64

Status: VERIFIED FIXED

(Core :: Graphics: Text, defect, P2)

Description

[ryan.brothers]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:64.0) Gecko/20100101 Firefox/64.0

Steps to reproduce:

I am running on Windows 7 with ClearType disabled, and with cairo listed before skia for gfx.canvas.azure.backends and gfx.content.azure.backends.  I noticed since upgrading to Firefox 64 that some websites are rendering with font smoothing enabled when they did not in Firefox 63.  2 examples are:

1) https://bugzilla.mozilla.org: if I go to it in Firefox 63, it renders without font smoothing, but I go to to it in Firefox 64, it renders with font smoothing.

2) https://news.google.com: the links along the left side have font smoothing, and then if I click one of the links such as "World", my browser itself starts to use font smoothing in the location bar and tabs.

My firefox settings are:

browser.preferences.defaultPerformanceSettings.enabled = false
gfx.canvas.azure.backends = direct2d1.1,cairo,skia
gfx.content.azure.backends = direct2d1.1,cairo,skia
layers.acceleration.disabled = true

Please let me know if I can give more information to help resolve this.  Thanks.



Actual results:

Websites rendered with font smoothing.


Expected results:

Websites should not have rendered with font smoothing.

Comment 1

[a29988122]

I too can confirmed that the rendering behavior once again changed - I have cleartype enabled, but there's visible font difference between firefox 63 and firefox 64.

Comment 2

[a29988122]

OK. 
By running mozregression, I successfully found the commit that is the cause of this issue.
https://bugzilla.mozilla.org/show_bug.cgi?id=1394709
This one.


====
This change is very buggy and very disrespectful to your user.

I DID NOT modify my font settings before or after the update, but the change is being enforced to user soon after update to FF 64. 

THIS IS VERY **** ANNOYING as I've already heard a dozen Traditional Chinese User complained about this - They are not engineers, they know 0 English, guess what will thy do? EZ, quit firefox once and for all. 

Also, I CAN NOT CHANGE the font back under FF64 no matter how I adjust the settings here. And yes I tried and tried.
https://imgur.com/a/b3s4q16

The only way's revert to FF63. NOT FF62.
It's very strange because according to mozregression, this commit appeared between FF62 and FF63, which is NOT THE CASE when I'm testing.


By the way despite I NEVER change the font settings in Chrome, the fonts there is normal. 
https://imgur.com/Uxu76BG

What I mean NORMAL is that no matter how you discussed in the abovementioned commit thread, I encountered 0 issue - that is - Chrome latest version font = FF 63 font

But FF64? BANG, **** JhengHei(or something else rather than customized chosen font in settings), **** unreadable.

Comment 3

[u554753]

Based off user comments here and settings chosen, I'm not entirely sure if this is an enhancement request or intended behavior. - I set the component for Layout: Text and Fonts so this can be looked at by the correct team.

Comment 4

[ryan.brothers]

Thanks, from my standpoint, this is a bug in Firefox 64.  Since I have ClearType disabled, I should not see any font smoothing in any website or in the Firefox UI itself, and it should not be different based on the website I'm browsing to.  Firefox 63 works properly.

Comment 5

[Jonathan Watt [:jwatt]]

(In reply to a29988122 from comment #2)
> OK. 
> By running mozregression, I successfully found the commit that is the cause
> of this issue.
> https://bugzilla.mozilla.org/show_bug.cgi?id=1394709

Thanks, tracking that down is very helpful.

Comment 6

[Jonathan Watt [:jwatt]]

I guess since this sounds like a regression we can start at P2.

Comment 7

[Jonathan Kew [:jfkthame]]

ryan, could you please attach screenshots comparing the result you see in Firefox 63 vs Firefox 64 for a given site (e.g. bugzilla.mozilla.org)? This sounds like something the Graphics team should look into. Lee, do we expect to see font smoothing changes between FF63 and 64 for any reason you're aware of?


Note that I'm not sure [e-mail]'s issue is the same thing; it sounds like they're complaining about a change to the default font configuration, but this is unrelated to the original report regarding font smoothing behavior. I very much doubt that the font  change from bug 1394709 is relevant to ryan.brothers's issue.

Comment 8

[Lee Salzman [:lsalzman]]

Can you please attach your "about:support" information?

Comment 9

[Lee Salzman [:lsalzman]]

In addition to attaching your "about:support", can you please use mozregression (https://mozilla.github.io/mozregression/) to help us track down what we changed that might have caused this?

Comment 10

[ryan.brothers]

Attachment: firefox_63.png

Comment 11

[ryan.brothers]

Attachment: firefox_64.png

Comment 12

[ryan.brothers]

Attachment: about_support.json

Comment 13

[ryan.brothers]

Thanks, attached are screenshots of Firefox 63 and 64 of bugzilla.mozilla.org and my about:support information.  I'll try out mozregression and let you know if I'm able to narrow it down.

Comment 14

[ryan.brothers]

mozregression found the below.  Please let me know if it helps.  Thanks again for your help.

2018-12-30T15:34:49: DEBUG : Found commit message:
Bug 1479640: Restructure cleartype parameter code to run less frequently and only in the parent process. r=jrmuizel

Differential Revision: https://phabricator.services.mozilla.com/D4784

Comment 15

[Jonathan Kew [:jfkthame]]

(In reply to ryan.brothers from comment #13)
> Thanks, attached are screenshots of Firefox 63 and 64 of
> bugzilla.mozilla.org

Thanks; that's a pretty glaring difference!

One point for clarification: what's happening in the Firefox 64 screenshot is not ClearType (subpixel antialiasing), it's grayscale font smoothing, which is a separate setting. I don't recall exactly where the system setting to completely disable font smoothing is found on Win7; somewhere in the System / Advanced control panel, maybe? Can you confirm whether you have this setting (it's called something like "Smooth edges of screen fonts", I think) turned off, as well as ClearType disabled (in the Fonts control panel, IIRC)?

Comment 16

[Jonathan Watt [:jwatt]]

(In reply to Jonathan Kew (:jfkthame) from comment #7)
> Note that I'm not sure [e-mail]'s issue is the same thing; it
> sounds like they're complaining about a change to the default font
> configuration, but this is unrelated to the original report regarding font
> smoothing behavior.

Based on that, and the fact that ryan.brothers narrowed his issue down to a different revision, can you open another bug for your issue please, a29988122? Add myself, [e-mail] and [e-mail] to the CC list.

Comment 17

[ryan.brothers]

Yes, I have both "Smooth edges of screen fonts" off and ClearType disabled.

Comment 18

[Jonathan Watt [:jwatt]]

Bas, it looks like bug 1479640 caused this regression. Maybe you could take a look?

Comment 19

[ryan.brothers]

Attachment: firefox_63_google_news.png

Comment 20

[ryan.brothers]

Attachment: firefox_64_google_news.png

Comment 21

[ryan.brothers]

Thanks, I attached 2 more examples from Google News if it helps.  Note here the location bar also has font smoothing.  It seems to do that based on the website visited.

Comment 22

[Lee Salzman [:lsalzman]]

Attachment: listen for font setting changes even if DWrite is not used

When DWrite is not used, we're no longer properly keeping track of the default anti-aliasing setting. This is a regression caused by bug 1479640.

The fix here is simple enough: we just need to listen for changes regardless of whether DWrite was used, which ensures the anti-aliasing settings are communicated appropriately regardless.

Comment 23

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/072522b854f3
listen for font setting changes even if DWrite is not used. r=jrmuizel

Comment 24

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/072522b854f3

Comment 25

[Ryan VanderMeulen [:RyanVM]]

Please nominate this for Beta approval when you get a chance so we can get this fix into 65.

Comment 26

[Lee Salzman [:lsalzman]]

Comment on attachment 9034756 [details] [diff] [review]
listen for font setting changes even if DWrite is not used

[Beta/Release Uplift Approval Request]

Feature/Bug causing the regression: Bug 1479640

User impact if declined: Windows font settings aren't always respected if the user's computer doesn't support DWrite.

Is this code covered by automated tests?: No

Has the fix been verified in Nightly?: No

Needs manual test from QE?: No

If yes, steps to reproduce:

List of other uplifts needed: None

Risk to taking this patch: Low

Why is the change risky/not risky? (and alternatives if risky): Just listens to Windows font setting changes in all cases now, regardless of whether DWrite is available, which is the previous behavior which the regression accidentally removed.

String changes made/needed:

Comment 27

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9034756 [details] [diff] [review]
listen for font setting changes even if DWrite is not used

[Triage Comment]
Fixes a pretty ugly font rendering regression introduced in Fx64 for some users. I do think we should get QA to verify this fix since we don't have automated test coverage for this. Approved for 65.0b10.

Comment 28

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/7755fe5f3b0a

Comment 29

[Vlad Lucaci, Desktop QA (:vlucaci)]

Hello ,
Managed to reproduce this issue on 64.0(20181206201918) on Windows 7x64 without ClearType activated and with the preffs from Description.

Confirming this issue as verified fixed on 65.0b10 and Nightly 66.0a1 (2019-01-11) on Win 7x64 and Windows 10x64.