857471 - Secondary text in the downloads panel doesn't have sub-pixel anti-aliasing

Status: NEW

(Firefox :: Downloads Panel, defect)

Description

[Stuart Cook]

Attachment: Screen Shot 2013-04-03 at 6.25.03 PM.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20130401 Firefox/21.0
Build ID: 20130401042013

Steps to reproduce:

Download any file, then open the downloads panel from the downloads button and closely inspect the text showing the file's size, domain, and download time.


Actual results:

The secondary text does not have sub-pixel anti-aliasing applied, which is inconsistent with the rest of the downloads panel and the rest of the Firefox UI.


Expected results:

All of the text in the downloads panel should have sub-pixel anti-aliasing.

Comment 1

[Stuart Cook]

I've observed this in Nightly 23 and Aurora 21 on OS X, and in Aurora 21 on Windows 7, so it doesn't appear to be a platform-specific issue.

Comment 2

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

I might be wrong, but I think we don't apply subpixel AA if the font size is below a certain threshold, cc-ing jonathan who may know.

Comment 3

[Jonathan Kew [:jfkthame]]

In general, we don't have a size threshold that would affect this. On Windows, at least, I believe we respect the font's "gasp" table, which can specify which hinting and antialiasing options should be applied at different sizes, so that could be a factor; not sure it has any effect on OS X, however.

I don't think size is the issue here, anyhow. I see subpixel AA on Lucida Grande at all sizes on OS X. (But I see the same grayscale-only text in the Downloads panel.) Are there elements involved that have varying opacity? That's often a trigger for grayscale-only AA, as subpixel AA doesn't get along well with general compositing of semi-transparent elements.

Comment 4

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

ah yes, that text has opacity: 0.7;

Comment 5

[Jonathan Kew [:jfkthame]]

OK, I suspect that's a factor (although -by itself- it wouldn't necessarily trigger this, I think; but perhaps in combination with the background).

Would it be reasonable to adjust the color instead of the opacity in its CSS?

Comment 6

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

it's possible, iirc the opacity was used to "adapt" to the OS font color settings (the panel uses the dialog color text) and the grey text was barely readable.

Comment 7

[Jonathan Kew [:jfkthame]]

As an experiment, I replaced opacity:0.7 with color:gray in browser/themes/osx/downloads/downloads.css, and sure enough, that results in subpixel-antialiased text here.

Of course, that wouldn't necessarily interact with other elements in exactly the same way, so I don't know whether it's acceptable to the design folk. Also, I see there are other uses of opacity:0.7 (in allDownloadsViewOverlay.css and places.css); similar considerations might apply to those.

Comment 8

[John Daggett (:jtd)]

(In reply to Marco Bonardo [:mak] from comment #4)
> ah yes, that text has opacity: 0.7;

Not quite sure using opacity is a great thing in UI elements that need to be readable but another option is to use an rgba color instead, this avoids the fallback to grayscale rendering caused by the use of opacity.  The semantics are slightly different but my guess is that would work for what you want.  Gray works too...

Just a general note that text "effects" like opacity and text-shadow will result in grayscale antialiasing so they should be used with caution.

Comment 9

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

yes, rgba sounds like a good idea.

Comment 10

[:Paolo Amadini]

I believe, in general, we used opacity since the colors are inherited from the
standard panel colors, defined in the Toolkit themes, that in turn may use
system colors (for example, inverting dark and light colors with some themes).

I don't know whether we use local colors, system colors or Toolkit-theme-defined
colors on the platforms where this issue has been specifically observed.