659213 - status bar text is drawn with grayscale anti-aliasing

Status: REOPENED

(Core :: Graphics: WebRender, defect)

Description

[John Daggett (:jtd)]

Steps:

1. Open about:support
2. Hover over the about:plugins link

Result: status bar is shown but the text is drawn with grayscale anti-aliasing rather than subpixel anti-aliasing.

Comment 1

[BRDTO]

This bug is still present in Firefox 5 (stable). There are several places were I saw Firefox 5 use greyscale-aa under Windows 7 (with Aero enabled).

Actually this bug applies to:
- tooltip texts
- the tooltip shown in the lower left when hovering over links
- adress bar
- search bar
- fonts on tabs (not always though, I'm not sure what's the reason yet)
- some dropdown lists on websites

This bug is quite annoying and makes the move to DirectDraw font rendering even more unappealing.

Comment 2

[BRDTO]

Attachment: Shows the places were greyscale anti aliasing is used instead of subpixel anti aliasing

I added an attachment were you can see all places were greyscale anti aliasing is used instead of subpixel anti aliasing (Though I couldn't find an example for a dropdown box yet).

I was able to reproduce the problem with a clean profile. Steps to reproduce:
- tooltip texts: simply hover mouse over an element that has a tooltip, e.g. the "flags"-sections of a bug entry on bugzilla.mozilla.org (not visible in the attachment but verified by me on the same page).
- the tooltip shown in the lower left when hovering over links: just hover over a link (see attachment)
- adress bar: set "Tabs on Top" to false. Nothing else needed to do (see attachment)
- search bar: set "Tabs on Top" to false. Nothing else needed to do (see attachment)
- fonts on tabs: visit https://bugzilla.mozilla.org and activate this tab, then all tabs will use greyscale anti aliasing (see attachment). On other pages, e.g. a blank page correct subpixel anti aliasing is used, though.

Comment 3

[Dão Gottwald [:dao]]

Removing the status panel's border radius fixes the rendering. Is it expected that border radii have this effect? If so, we can avoid them there. We can't do this for tooltips, where we are using native theming.

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to Dão Gottwald [:dao] from comment #3)
> Removing the status panel's border radius fixes the rendering. Is it
> expected that border radii have this effect?

No... We should be using a component alpha layer for it...

Comment 5

[Timothy Nikkel (:tnikkel)]

On Linux at least I get subpixel AA in the status panel.

Comment 6

[Dão Gottwald [:dao]]

So what's the likelihood that this will get fixed in the foreseeable feature? I'd like to work around it, but then it probably won't be on anyone's radar anymore?

Comment 7

[Dão Gottwald [:dao]]

Attachment: workaround

Comment 8

[Dão Gottwald [:dao]]

Attachment: screenshot with and without workaround

Comment 9

[Stephen Horlander [:shorlander]]

Comment on attachment 581577 [details] [diff] [review]
workaround

Review of attachment 581577 [details] [diff] [review]:
-----------------------------------------------------------------

Looks goods until the bug gets fixed. Thanks!

Comment 10

[Dão Gottwald [:dao]]

Comment on attachment 581577 [details] [diff] [review]
workaround

http://hg.mozilla.org/mozilla-central/rev/f63a99195987

Comment 11

[Dão Gottwald [:dao]]

Comment on attachment 581577 [details] [diff] [review]
workaround

This simply comments out a CSS property in order to improve the text rendering quality on the status panel. Can this land on aurora?

Comment 12

[LegNeato]

Comment on attachment 581577 [details] [diff] [review]
workaround

[triage comment]
Normally this wouldn't meet the standard for an aurora backport but the patch looks trivial and it's early in the cycle. Approved for aurora.

Comment 13

[Dão Gottwald [:dao]]

http://hg.mozilla.org/releases/mozilla-aurora/rev/60334bde46a0

Comment 14

[Alfred Kayser]

Note, with a radius of 5px it doesn't grayscale, but with 6px and higher it does.
So, setting a smaller radius of like 3px should remove this unwanted effect.

Comment 15

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Per Comment 10 and Comment 12 closing this one.

@ Dão Gottwald [:dao] - Do you agree with this?

Comment 16

[Dão Gottwald [:dao]]

No, the workaround didn't fix the underlying issue.

Comment 17

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

There is no backout information and "status-firefox11" is marked as "fixed".

But staying on the issue, it should be fixed starting from Mozilla Firefox 52 per:
- Skia being enabled by default(Windows - bug #1007702, Linux - bug #1278957, Mac - bug #1207332)
- bug #1303570

Leftovers will be tracked in bug #1307833 (which was caused by bug #1306670).

So I'm duping this bug to bug #1307833 to later easier tracking.

Comment 18

[Dão Gottwald [:dao]]

(In reply to Virtual_ManPL [:Virtual] - (ni? me) from comment #17)
> There is no backout information and "status-firefox11" is marked as "fixed".

Because we landed a workaround.

> But staying on the issue, it should be fixed starting from Mozilla Firefox
> 52 per:
> - Skia being enabled by default(Windows - bug #1007702, Linux - bug
> #1278957, Mac - bug #1207332)
> - bug #1303570

What makes you think so? This is not fixed.

> Leftovers will be tracked in bug #1307833 (which was caused by bug #1306670).
> 
> So I'm duping this bug to bug #1307833 to later easier tracking.
> 
> *** This bug has been marked as a duplicate of bug 1307833 ***

Please stop doing that. Folding different bug reports with different contexts into a single bug is a safe way to lose track of issues. If bug 1307833 ends up fixing this, great. Bug dependencies are the right way to express this kind of relationship.

Comment 19

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

(In reply to Dão Gottwald [:dao] from comment #18)
> (In reply to Virtual_ManPL [:Virtual] - (ni? me) from comment #17)
> > There is no backout information and "status-firefox11" is marked as "fixed".
> 
> Because we landed a workaround.
If it isn't working shouldn't it be backed out?


> > But staying on the issue, it should be fixed starting from Mozilla Firefox
> > 52 per:
> > - Skia being enabled by default(Windows - bug #1007702, Linux - bug
> > #1278957, Mac - bug #1207332)
> > - bug #1303570
> 
> What makes you think so? This is not fixed.

Maybe you missed, but I also wrote about bug #1303570.

Comment 20

[Dão Gottwald [:dao]]

The workaround is working as expected and will not be backed out as long as the underlying issue still exists, and it does very much still exist.

Comment 21

[Dão Gottwald [:dao]]

Need to check if this is still an issue.

Comment 22

[Dão Gottwald [:dao]]

(In reply to Dão Gottwald [:dao] from comment #21)

Need to check if this is still an issue.

It's still an issue.