1096012 - Tab-titles without favicons only use grayscale antialiasing

Status: REOPENED

(Core :: Graphics: Text, defect)

Description

[Elbart]

STR:
Open about:newtab (grayscale) and about:home (cleartype) and switch between them.

Or alternatively
http://www.trilithium.com/johan/2005/02/no-favicon/ (grayscale)
and
http://www.google.com (cleartype)

Or
http://elbart.bplaced.net/test_favicon_no.htm (grayscale)
and
http://elbart.bplaced.net/test_favicon.htm (cleartype)


Regression-ranges:
m-c:
Ever since the merge of ux on 2013-11-19

ux:
First regression where grayscale was used for all tabtitles instead of cleartype:
Last good revision: 902b4c695658 (2012-11-13)
First bad revision: a2a83a2c24cf (2012-11-14)
Pushlog:
http://hg.mozilla.org/projects/ux/pushloghtml?fromchange=902b4c695658&tochange=a2a83a2c24cf


Second regression where cleartype for titles with favicons was fixed:
Last good revision: a9e45ebd6683 (2013-09-13)
First bad revision: 14a05f3555df (2013-09-14)
Pushlog:
http://hg.mozilla.org/projects/ux/pushloghtml?fromchange=a9e45ebd6683&tochange=14a05f3555df

Comment 1

[Elbart]

Attachment: favicon_aa_edited.png

Comment 2

[Kanchan Kumari QA]

Hello Reporter, it seems that the behavior that you are observing is the expected one. I would request you to look into the details and comments of bug 994640 (comment #3). If you agree I will go ahead and close this bug. Please let us know.

Comment 3

[Jonathan Kew [:jfkthame]]

(In reply to Kanchan Kumari QA from comment #2)
> Hello Reporter, it seems that the behavior that you are observing is the
> expected one. I would request you to look into the details and comments of
> bug 994640 (comment #3).

No, that's not what the reporter is talking about.

The issue reported here is that the text of the tab title is being rendered differently (cleartype antialiasing vs grayscale antialiasing) depending on whether there's a favicon or not.

That seems like a genuine bug: the presence or absence of the icon shouldn't affect how the text is rendered.

Given the age of this report, however, the obvious question arises: does this still occur with current versions, or has it gotten resolved in the meantime?

Comment 4

[Elbart]

(In reply to Jonathan Kew (:jfkthame) from comment #3)
> Given the age of this report, however, the obvious question arises: does
> this still occur with current versions, or has it gotten resolved in the
> meantime?

Still happening.

Comment 5

[Jonathan Kew [:jfkthame]]

OK, I checked on my Win8.1 laptop and I can confirm I'm seeing the same thing, both with Firefox 45 (release) and 48 (nightly).

I guess the presence of the favicon may be affecting how things get layerized, or something like that, and that in turn determines whether subpixel AA gets used. So it's not necessarily a "Graphics:Text" issue per se; it might be more appropriate under Layers? Or is it something about how the front-end is constructed, that in turn influences how layers are created...?

On my (very high-dpi) screen, the effect is barely visible, but for users with lower-res displays the discrepancy will tend to be more glaring. ISTM we should be able to arrange for the text in tab titles to render consistently with subpixel AA regardless of the presence or absence of the favicon.

Comment 6

[lmlb_lmlb]

I found that it happens when .tab-label overlaps .tab-background-start or .tab-background-end (I believe the latter can currently only happen when something like an addon or a user style hides the tab close button).

Comment 7

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

Can you still reproduce the issue in latest stable Firefox version or in latest Nightly?

Comment 8

[Elbart]

Attachment: favicon yes.htm

Yes.

Comment 9

[Elbart]

Attachment: favicon no.htm

Comment 10

[Elbart]

Attachment: favicon no.htm

Comment 11

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

Please attach as attachment here your about:support (use "copy text to clipboard" button) from Nightly.

Comment 12

[Elbart]

To what end? It's happening independent of gfx-card or driver-version, with a new profile and with e10s on and off.

Comment 13

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

To all end and I wasn't talking about dependency, I was talking about complete information from about:support from Nightly. Could you post it?

Comment 14

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

I'm asking because it could be fixed in Nightly which contains fixes for bug #1007702 and bug #1303570,
about:support is needed for checking what preferences are modified and backended is used where.

Comment 15

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

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).

Duping this bug to bug #1307833 to later easier tracking, instead of incomplete or worksforme, because of no reporter reply.

Comment 16

[Dão Gottwald [:dao]]

Using Skia doesn't magically make us use sub-pixel AA where we were using grayscale AA. Please test this before concluding that it's fixed.

Comment 17

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

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