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

Steps to reproduce:

See attached image: the font on inactive tabs is "dizzy" on my machine since update to 69.0. The screenshot contains also the same tabs with firefox portable 67.0.

I have Windows 10 1903, Firefox x64, graphics card is NVidia Geforce GT 1030

My theme settings should be default.

On my computer at home (linux), the screenshot (!!) looks quite OK - the font lines in the new firefox version are just a bit smaller than in the old version, but both versions are good to read. On the Win10 machine, even in the screenshot it seems as if antialiasing of the font of the new firefox version did not work properly.

Hi @Wolfgang Knauf, I've checked the issue on Windows 10 1809 platform having graphics NVIDIA GeForce GT 1030 - & FF versions: nightly 71.0a1 vs release 69.0. Looking at your screenshot, can't figure it out what may be the issue; what should I focus?
Please add suitable new info.
Regards,
Liviu

In the screenshots, it looks like Firefox 69 is rendering the inactive tab with grayscale antialiasing, whereas in the portable-67 version it uses subpixel AA, which tends to make the text look "stronger".

I'm not sure why the difference offhand. On my Windows machine, I get subpixel AA on both active and inactive tabs.

It's possible an add-on or something like that might affect how the tabs render. Could you try Safe Mode and see if the issue remains?

Regression range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e9e463c46a688e1d97e7ca8fbf8ced1498cb11fe&tochange=f03d8ccb0864e36d3a106a38db23b94fb9c8a174

Regressed by: bug 1553818

Note that the bug 1553818 does not deal with the user's problem as reported here, where subpixel AA is being disabled for inactive tabs. That only deals with the gamma being different, which is also addressed in bug 1578791, the origins of which are already discussed and that as such is not a regression, but may require some UX intervention to compensate for the fix made in that bug.

As for the subpixel vs grayscale AA, it would help if we had access to "about:support" information for both 67 and 69 so we could see if you are taking different rendering paths which might be affecting it. Wolfgang, could you paste both the 67/69 about:supports?

Attached are the "about:support" files.

Just to clarify: the issue started on my machine after the update to 69.0. The previous version 68 (regular installation - not firefox portable) did not show this issue.

So it looks like as of 69 you were automatically opted into WebRender for content rendering, whereas prior to that, you were using the Direct2D content backend. That might at least explain the divergence with you no longer having subpixel AA on the inactive tab titles.

Glenn or Alexis, do you have an idea of why subpixel AA might be getting disabled there?

The most likely reason for subpixel AA getting disabled is if WR (probably incorrectly) thinks that the background is not opaque.

I just tested FF69 and also FF nightly on my Windows machine, and they are both correctly using subpixel AA for both the active and inactive tab titles, so I haven't been able to reproduce this.

I wonder if it might be related to either the current Windows DPI settings or which theme is enabled in Firefox? I was testing with 100% scale settings and the default theme. Is your machine different from those?

Another possibility is that it depends on the length of the text in the tab title - Wolfgang, does it seem to happen on every tab title, or does it only occur on certain pages?

Is anyone else able to reproduce locally?

It think it also happens for the new tab (in german: "Neuer Tab"), even if I restart firefox and open two empty tabs.

Sorry, I did not see your other questions: no firefox theme enabled, and windows has default dpi.

The problem is that the text of the tab is overflowing, triggering the fadeout effect. You can also see this in the URL Bar if the URL is too long.

This fadeout affect is an alpha mask, which makes webrender abandon subpixel-aa. This is a long-known fundamental regression introduced by webrender, as alpha masked content can only be composited with Component Alpha, a system webrender fundamentally rejects.

Last time I looked into this (~2 years ago), Chrome also has this issue, but they do a little trick: they only fall back to greyscale-aa where the mask is. So the bulk of the text is subpixel, but it transitions to greyscale at the boundary.

If this is important to us, we could also look into doing that. We could do it in one of two ways:

• Detect "partially masked" content in webrender's backend and handle it automatically (just a good thing to have for QoI, but maybe very hard)
• Have the browser's layout code carefully split the text into two parts for us (potentially tricky and brittle, as the frontend designers need to "know" this is a thing)

Ok discussed this a bit with mstange, and subpixel text in WR is a lot more robust than it used to be, so it actually shouldn't be too bad for us to detect this in the WR backend and handle it!

Specifically we already have the machinery to draw transparent text with subpixel-aa, but we conservatively don't do this when drawing masked text, which is correct if there's a bunch of overlapping masked stuff. However, if the contents of the mask are only text, or if the text is disjoint from all the other contents, we should be able to do subpixel masking.

In the case of tabs and the url bar, this should indeed be the case. Hopefully just the simpler "is alone" check is sufficient.

This testcase was made by Alice0775 White in bug 1678184 comment 11.