User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:90.0) Gecko/20100101 Firefox/90.0

Steps to reproduce:

Firefox 90.0.2 on Fedora Linux 34 does not have subpixel anti-aliasing in tab bar, address bar, sidebar, bookmark bar with default settings.
The website content has anti-aliasing.

Actual results:

This bug seems to be in WebRender. If I disable WebRender (gfx.webrender.force-disabled=true) and restart the browser, sidebar, tab bar and address bar will have subpixel AA again.

Expected results:

All elements should have subpixel AA with WebRender, just as it is without.

This is a screenshot with a fresh Firefox profile with default settings, with WebRender.
RED means only grayscale anti-aliasing
GREEN means proper subpixel anti-aliasing.

Bookmarks sidebar with WebRender, no subpixel AA

Now if I disable WebRender (gfx.webrender.force-disabled=true) and restart the browser, every text displayed on the screen has subpixel anti-aliasing.

Additional information:

Linux Fedora 34, KDE Plasma 5, Lenovo ThinkPad X220 laptop with Intel HD 3000 graphics, X11.
Firefox 90.0.2 from official Fedora repository.

Attached file contains about:support information when WebRender enabled and when disabled.

The Bugbug bot thinks this bug should belong to the 'Firefox::Address Bar' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Passing this to graphics for a first pass.

:gw, can you comment to the bug?

There's a number of reasons we sometimes don't get subpixel AA where non-WR did (sometimes simple bugs, sometimes a known issue requiring some refactoring to fix, sometimes a deliberate choice to enable optimizations / integration with the system compositor where it's not feasible).

I'll need to investigate each of these cases to see which of the above they fall in to.

I suspect this might be one of the easier cases to fix (we may not be calculating an appropriate opaque background region rect if the picture cache slice background has a rounded rect clip on it, which we can handle easily enough if that's the case).

I was able to get a WR capture of the issue with the megabar dropdown open.

The issue is what I suspected - that we don't find a valid (by the current conservative WR definition) background rect that is opaque to enable subpixel AA on that surface.

I hacked out the check for a rounded-rect clip to see if that was the problem. It improves this case, but doesn't fix it. We end up finding a partial opaque background rect which allows subpixel AA on some of the text, but not all.

This still needs further investigation - we should be able to do a better job in WR of finding and opaque background rect for this case, I think, which would enable subpixel AA on the entire surface. Another option is to try and change the front-end UI to have a complete opaque background rect in the display list here, but I don't think that should be necessary.

This also applies to Firefox 91 on Windows. Not only Linux.

The issue present in Firefox 93.
The issue also applies to Thunderbird 91 (https://bugzilla.mozilla.org/show_bug.cgi?id=1732583).

Darkspirit, bug 1732583 is for Thunderbird. This bug is for Firefox.

Wayne Mery, seems I've accidentally removed the depending bug bug can't apply it again.

"Product: Core" affects Firefox and Thunderbird.

Please leave the "version" field set to the version with which the bug was originally reported. We can track future/other affected versions using the status flags (which are already set for this bug anyway).

Sometimes subpixel anti-aliasing is not used on the websites as well.
For example, I've just spotted it on this page: https://qna.habr.com/q/1106580#comment_2967552
But after refreshing the page subpixel anti-aliasing is usually applies again.
Seen that at least twice on different websites.

(In reply to ValdikSS from comment #17)

Sometimes subpixel anti-aliasing is not used on the websites as well.
For example, I've just spotted it on this page: https://qna.habr.com/q/1106580#comment_2967552
But after refreshing the page subpixel anti-aliasing is usually applies again.
Seen that at least twice on different websites.

Please file a separate bug for this, the fix is likely going to need to be different.

Firefox 103.0.2.
Everything is the same (no subpixel anti-aliasing in many places), except now the active tab text does have subpixel anti-aliasing.

(In reply to Glenn Watson [:gw] from comment #9)

I was able to get a WR capture of the issue with the megabar dropdown open.

The issue is what I suspected - that we don't find a valid (by the current conservative WR definition) background rect that is opaque to enable subpixel AA on that surface.

I hacked out the check for a rounded-rect clip to see if that was the problem. It improves this case, but doesn't fix it. We end up finding a partial opaque background rect which allows subpixel AA on some of the text, but not all.

This still needs further investigation - we should be able to do a better job in WR of finding and opaque background rect for this case, I think, which would enable subpixel AA on the entire surface.

Is that investigation happening in bug 1770816? Or a different bug?

I'm not actively working on it right now. I did find that some of the cases are caused by XUL views which are blob rasterized, these cases will likely need to converted to use WR display items. Some of the other cases are related to the WR issue mentioned above.

Windows 10, Firefox 107.0.

Zoomed-in part without subpixel anti-aliasing, #1

Zoomed-in part without subpixel anti-aliasing, #2

Firefox 108.0 b9 (downloaded from Mozilla), Fedora Linux 35:

• Pressing on the address bar disables subpixel anti-aliasing for the text in address bar
• Drop-down menu in the address bar does not have subpixel anti-aliasing
• Bookmarks in bookmark bar are constantly changing between subpixel anti-aliasing and grayscale upon hovering

Issue in Thunderbird 102.5.0

Is it possible that bug 1820534 fixed this?

I did find that some of the cases are caused by XUL views which are blob rasterized, these cases will likely need to converted to use WR display items

Probably not the XUL trees, no.

As of Firefox 113.0, most of the issues mentioned in comment 1 and 2 (on the screenshots) still apply.
The only thing which is fixed is subpixel anti-aliasing on the tab title, but only when it's not overflowing the tab button length.

No subpixel anti-aliasing for:

• Tab titles which overflow tab button length
• Text inside address bar when the bar was clicked (and recent website menu opened)
• Text of recent website menu items
• Bookmarks sidebar

(In reply to Gregory Pappas [:gregp] from comment #28)

Is it possible that bug 1820534 fixed this?

I did find that some of the cases are caused by XUL views which are blob rasterized, these cases will likely need to converted to use WR display items

As far as I understand, this change is shipped in 113.0. If so — not fixed.