Open Bug 659213 Opened 9 years ago Updated 3 years ago

status bar text is drawn with grayscale anti-aliasing

Categories

(Core :: Graphics, defect)

x86
Windows 7
defect
Not set

Tracking

()

REOPENED

People

(Reporter: jtd, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(3 files)

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.
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.
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.
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.
Component: General → Graphics
Product: Firefox → Core
QA Contact: general → thebes
Version: 4.0 Branch → Trunk
No longer blocks: 635490
See Also: → 659211
(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...
On Linux at least I get subpixel AA in the status panel.
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?
Attached patch workaroundSplinter Review
Attachment #581577 - Flags: review?(shorlander)
Comment on attachment 581577 [details] [diff] [review]
workaround

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

Looks goods until the bug gets fixed. Thanks!
Attachment #581577 - Flags: review?(shorlander) → review+
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?
Attachment #581577 - Flags: approval-mozilla-aurora?
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.
Attachment #581577 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
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.
Per Comment 10 and Comment 12 closing this one.

@ Dão Gottwald [:dao] - Do you agree with this?
Assignee: nobody → dao+bmo
Status: NEW → RESOLVED
Closed: 3 years ago
Flags: needinfo?(dao+bmo)
Resolution: --- → FIXED
No, the workaround didn't fix the underlying issue.
Status: RESOLVED → REOPENED
Flags: needinfo?(dao+bmo)
Resolution: FIXED → ---
Assignee: dao+bmo → nobody
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.
Status: REOPENED → RESOLVED
Closed: 3 years ago3 years ago
Resolution: --- → DUPLICATE
See Also: 659211
Duplicate of bug: 1307833
(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.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Blocks: 1307833
(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.
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.
You need to log in before you can comment on or make changes to this bug.