status bar text is drawn with grayscale anti-aliasing

REOPENED
Unassigned

Status

()

Core
Graphics
REOPENED
6 years ago
10 months ago

People

(Reporter: jtd, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
x86
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

6 years ago
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

6 years ago
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

6 years ago
Created attachment 544498 [details]
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.
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

Updated

6 years ago
No longer blocks: 635490
See Also: → bug 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?
Created attachment 581577 [details] [diff] [review]
workaround
Attachment #581577 - Flags: review?(shorlander)
Created attachment 581578 [details]
screenshot with and without workaround
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

http://hg.mozilla.org/mozilla-central/rev/f63a99195987
Attachment #581577 - Flags: checkin+
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 12

6 years ago
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+
http://hg.mozilla.org/releases/mozilla-aurora/rev/60334bde46a0
status-firefox11: --- → fixed

Comment 14

6 years ago
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
Last Resolved: 10 months ago
Flags: needinfo?(dao+bmo)
Resolution: --- → FIXED

Comment 16

10 months ago
No, the workaround didn't fix the underlying issue.
Status: RESOLVED → REOPENED
Flags: needinfo?(dao+bmo)
Resolution: FIXED → ---

Updated

10 months ago
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
Last Resolved: 10 months ago10 months ago
status-firefox11: fixed → ---
Resolution: --- → DUPLICATE
See Also: bug 659211
Duplicate of bug: 1307833

Comment 18

10 months ago
(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 → ---

Updated

10 months ago
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.

Comment 20

10 months ago
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.