Open Bug 1307833 Opened 8 years ago Updated 2 years ago

[meta] Grayscale antialiasing instead of subpixel antialiasing is still used in some places on Mozilla Firefox Nightly 52.0a1 (2016-10-05)

Categories

(Core :: Graphics: Text, defect, P3)

Product:
Core
Component:
Graphics: Text
Version:
52 Branch
Platform:
x86_64
Windows 7
Type:
defect

Tracking

()

Status:
ASSIGNED
Tracking Flags:
Tracking Status
firefox49 --- unaffected
firefox-esr45 --- unaffected
firefox50 --- unaffected
firefox51 --- wontfix
firefox52 + wontfix
firefox-esr52 - wontfix
firefox-esr60 --- wontfix
firefox53 + wontfix
firefox54 + wontfix
firefox55 - wontfix
firefox56 - wontfix
firefox57 --- wontfix
firefox58 --- wontfix
firefox59 --- wontfix
firefox60 --- wontfix
firefox61 --- wontfix
firefox62 --- wontfix
firefox63 --- wontfix
firefox64 --- wontfix
firefox65 --- wontfix
firefox66 --- wontfix
firefox67 --- wontfix
firefox67.0.1 --- wontfix
firefox68 --- wontfix

People

(Reporter: Virtual, Assigned: mstange)

References

(Depends on 9 open bugs, Blocks 1 open bug)

Details

(5 keywords, Whiteboard: [gfx-noted])

User Story

Grayscale antialiasing instead of subpixel antialiasing is used in fonts text on:
- tooltip
- downloaded status in Download button
- downloading status in Download button
- sub-menu in "hamburger" button (fixes itself after moving mouse pointer on it)
- bookmark folder menu (after scrolling long list)
- background tab title
- foreground tab title and in address bar (with Persona/light theme)
- long tab title [bug #1370064] (caused by bug #658467)
- address bar (especially long address) [bug #1366240] (caused by bug #653670)
-search bar (after scrolling long list)
-omnibox dropdown
-during the fade-in animation, the text in the popup is using subpixel AA
-after the animation, it's in grayscale AA (unless the final opacity is changed to 1.0), and the hinting is still the same
-developer tools in inspector: event handlers popup
-developer tools in debugger: pause/step over/... icons

STR:
1. Go to places about which I wrote above
2. If you can't locate them, use attachments as your hints

Reproducible on:
latest Firefox (32-bit and 64-bit) on Windows 7 (32-bit and 64-bit)

Attachments

(10 files, 6 obsolete files)

grayscale antialiased font in text on tooltip.png
566.60 KB, image/png
Details
grayscale antialiased font in text on downloaded status in Download button.png
400.60 KB, image/png
Details
grayscale antialiased font in text on downloading status in Download button.png
401.50 KB, image/png
Details
grayscale antialiased font in text on submenu.png
581.95 KB, image/png
Details
grayscale antialiased font in text on submenu (top part) and supixel antialiasted font in text on submenu (bottom part, after moving mouse pointer on it).png
580.58 KB, image/png
Details
subpixel antialiased font in text on bookmark folder menu (before scrolling).png
562.47 KB, image/png
Details
grayscale antialiased font in text on bookmark folder menu (after scrolling).png
561.59 KB, image/png
Details
grayscale antialiased font in text on background tab (without Persona).png
564.97 KB, image/png
Details
grayscale antialiased font in text on foreground tab and location bar (with Persona).png
563.15 KB, image/png
Details
about:support.txt
7.81 KB, text/plain
Details
Attached image blurry submenu.png (obsolete) — 
The awful blurry fonts are back in Mozilla Firefox Nightly 52.0a1 (2016-10-05)


STR - Just see:
- hamburger submenu
- tooltips
- bookmarks menu and submenu after scrolling
and there could be other places affected.


Regression window (mozilla-central)
Good:
https://ftp.mozilla.org/pub/firefox/nightly/2016/10/2016-10-04-03-02-04-mozilla-central/

Bad:
https://ftp.mozilla.org/pub/firefox/nightly/2016/10/2016-10-05-03-02-11-mozilla-central/

Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=42c95d88aaaa7c2eca1d278399421d437441ac4d&tochange=ea104eeb14cc54da9a06c3766da63f73117723a0

Probably caused by:
df26b07efb46	Bas Schouten — Bug 1306670: Properly disable cleartype when the underlying surface indicates it may not be opaque. r=jrmuizel


[Tracking Requested - why for this release]: Regression
Flags: needinfo?(bas)
Has Regression Range: --- → yes
Has STR: --- → yes
Tracking 52+ for this font issue.
tracking-firefox52: ? → +
Attached file webexttest.xpi (obsolete) — 
Does the following issue also fit in this bug, or should I file a separate one?  
- See screencast: http://screencast.com/t/cgqrsEnBWpp
- I am attaching the webextension used in screencast.
- Reproduces on Firefox 52.0a1 (2016-10-06) under Windows 10 64-bit.
Flags: needinfo?(virtual)
Priority: -- → P3
Whiteboard: [gfx-noted]
(In reply to Vasilica Mihasca, QA [:vasilica_mihasca] from comment #6)
> Created attachment 8798763 [details]
> webexttest.xpi
> 
> Does the following issue also fit in this bug, or should I file a separate
> one?  
> - See screencast: http://screencast.com/t/cgqrsEnBWpp
> - I am attaching the webextension used in screencast.
> - Reproduces on Firefox 52.0a1 (2016-10-06) under Windows 10 64-bit.

Try reproducing it on one of Nightly builds dated from (2016-09-30) to (2016-10-04),
and if it isn't occurring, it could be the same issue,
but if it reproducible, it's other issue.
Flags: needinfo?(virtual)
We should stop calling this 'blurry' it's not a very accurate description for the issue. But regardless. I'll have a look at this. We'll have to figure out why layout thinks we should use grayscale AA for this case, as far as I can tell at least in one of these cases the text is actually over opaque pixels.
Flags: needinfo?(bas)
Summary: Awful blurry fonts in text are back in some places on Mozilla Firefox Nightly 52.0a1 (2016-10-05) → Grayscale AA instead of subpixel AA used in some places on Mozilla Firefox Nightly 52.0a1 (2016-10-05)
(In reply to Bas Schouten (:bas.schouten) from comment #8)
> We should stop calling this 'blurry' it's not a very accurate description
> for the issue. But regardless. I'll have a look at this. We'll have to
> figure out why layout thinks we should use grayscale AA for this case, as
> far as I can tell at least in one of these cases the text is actually over
> opaque pixels.

Is it the same for the tooltips ?
IMHO when subpixel AA can't be used due to transparency, then a strong hinting should be applied.
Mixing grayscale AA with an hinting mode meant for subpixel AA is what makes text blurry when not using a high DPI screen.
(In reply to Bas Schouten (:bas.schouten) from comment #8)
> We should stop calling this 'blurry'
> it's not a very accurate description for the issue.

It's very accurate description from the user point of view,
as text fonts looks simply less sharper and more blurrier with grayscale antialiasing compared to subpixel antialiasing.

But thank you very much for changing summary to the technical description.


(In reply to Bas Schouten (:bas.schouten) from comment #8)
> We'll have to figure out why layout thinks
> we should use grayscale AA for this case,
> as far as I can tell at least in one of these cases
> the text is actually over opaque pixels.
+
(In reply to Loïc Yhuel from comment #9)
> IMHO when subpixel AA can't be used due to transparency

Maybe faster way for fixing this will be changing how the "base" works,
like changing tooltip, submenu, menu etc. "deep" settings,
like opaque, transparency, etc., as other tooltip, submenu and menu are rendered in proper way.
Summary: Grayscale AA instead of subpixel AA used in some places on Mozilla Firefox Nightly 52.0a1 (2016-10-05) → Grayscale antialiasing instead of subpixel antialiasing is still used in some places on Mozilla Firefox Nightly 52.0a1 (2016-10-05)
(In reply to Loïc Yhuel from comment #9)
> (In reply to Bas Schouten (:bas.schouten) from comment #8)
> > We should stop calling this 'blurry' it's not a very accurate description
> > for the issue. But regardless. I'll have a look at this. We'll have to
> > figure out why layout thinks we should use grayscale AA for this case, as
> > far as I can tell at least in one of these cases the text is actually over
> > opaque pixels.
> 
> Is it the same for the tooltips ?
> IMHO when subpixel AA can't be used due to transparency, then a strong
> hinting should be applied.
> Mixing grayscale AA with an hinting mode meant for subpixel AA is what makes
> text blurry when not using a high DPI screen.

In theory, we -should- be doing that. That's all in layout land though so I don't know that code well, but glyphs should not be subpixel positioned and strongly hinted when we decide to disable subpixel AA. Do you know if we've ever verified this is working correctly Jonathan?
Flags: needinfo?(jfkthame)
Hmm, so all the menus I've checked on my local build with today's nightly seem to get subpixel AA just fine now. Are there any custom settings you've got that might affect this? Could you try with a clean profile?
(In reply to Bas Schouten (:bas.schouten) from comment #12)
> Are there any custom settings you've got that might affect this?
Depends.
In some there's trick to it, like:
- pointing options in menu (comment 16 & comment 17)
- scrolling menu (comment 18  & comment 19)
- disabled/enabled Persona (comment 20 & comment 21)

(In reply to Bas Schouten (:bas.schouten) from comment #12)
> Could you try with a clean profile?
I can reproduce it with clean profile (with Persona in one case).
(In reply to Bas Schouten (:bas.schouten) from comment #11)
> In theory, we -should- be doing that. That's all in layout land though so I
> don't know that code well, but glyphs should not be subpixel positioned and
> strongly hinted when we decide to disable subpixel AA. Do you know if we've
> ever verified this is working correctly Jonathan?

I don't specifically know, though I'm fairly sure that used to be the case. My impression is that there have been a flurry of recent reports of things like this, which strongly suggests there has been a specific, user-visible regression. But I haven't been closely following a lot of the recent work that may have affected rendering (wondering about stuff around moz2d-ification, skia-ification, layers, ...).

Here's an odd thing: looking at the first screenshot posted here (attachment 8798121 [details]), the last menu item "About Nightly" has subpixel antialiasing, while all the earlier items are grayscale (but they look like glyphs that were rasterized for subpixel rendering, then "flattened" to grayscale, hence their "blurry" appearance). I have no idea why... surely we ought to be using the same rendering throughout the menu.

(In a new shot of that menu just posted in attachment 8799328 [details], however, even the "About Nightly" item is grayscale/blurry. Inconsistent/unpredictable...? Maybe separate tiles sometimes end up rendering differently?)
Flags: needinfo?(jfkthame)
(In reply to Jonathan Kew (:jfkthame) from comment #24)
> Here's an odd thing: looking at the first screenshot posted here (attachment
> 8798121 [details]), the last menu item "About Nightly" has subpixel
> antialiasing, while all the earlier items are grayscale (but they look like
> glyphs that were rasterized for subpixel rendering, then "flattened" to
> grayscale, hence their "blurry" appearance). I have no idea why... surely we
> ought to be using the same rendering throughout the menu.
> 
> (In a new shot of that menu just posted in attachment 8799328 [details],
> however, even the "About Nightly" item is grayscale/blurry.
> Inconsistent/unpredictable...? Maybe separate tiles sometimes end up
> rendering differently?)

It's due to mouse pointer movement.
If you open this submenu it will renderer fonts in text with grayscale antialiasing (Comment #16),
but when you move mouse pointer on some option, the fonts in text in this option will be re-renderered with subpixel antialiasing (Comment #17) [this not marked on green are re-rendered].

Next odd thing is that using Persona (Appearance/Light Theme) will reverse used antialiasing scaling method on tabs titles and Location Bar(Comment #20 & Comment #21).
Oddly Search Bar stays intact with subpixel antialiasing.
Attachment #8799332 - Attachment description: grayscale antialiased font in text on background tab (without Perona).png → grayscale antialiased font in text on background tab (without Persona).png
Attachment #8799332 - Attachment filename: grayscale antialiased font in text on background tab (without Perona).png → grayscale antialiased font in text on background tab (without Persona).png
Attachment #8799333 - Attachment description: grayscale antialiased font in text on foreground tab and adress bar (with Persona).png → grayscale antialiased font in text on foreground tab and location bar (with Persona).png
Attachment #8799333 - Attachment filename: grayscale antialiased font in text on foreground tab and adress bar (with Persona).png → grayscale antialiased font in text on foreground tab and location bar (with Persona).png
(In reply to Virtual_ManPL [:Virtual] - (ni? me) from comment #7)
 
> Try reproducing it on one of Nightly builds dated from (2016-09-30) to
> (2016-10-04),
> and if it isn't occurring, it could be the same issue,
> but if it reproducible, it's other issue.

Testing on Firefox 52.0a1 (2016-10-03) I reproduced Bug 1306670 - http://screencast.com/t/jThhjhfMM . Considering that this bug is a regression from Bug 1306670, I think that my issue it’s practically the same with the one reported here.
The search bar loses subpixel AA when the text scroll (ie if the text width is bigger than the search bar). Then, even after erasing the text, subpixel AA stays disabled in the search bar for the window.
Also in developer tools :
 - in inspector, event handlers popup
 - in debugger, pause/step over/... icons (if it's text, perhaps it's SVG) : the pause it really ugly, as the first vertical bar is two pixel wide, and the second is one pixel wide
(In reply to Bas Schouten (:bas.schouten) from comment #11)
> In theory, we -should- be doing that. That's all in layout land though so I
> don't know that code well, but glyphs should not be subpixel positioned and
> strongly hinted when we decide to disable subpixel AA. Do you know if we've
> ever verified this is working correctly Jonathan?
For example : https://code.woboq.org/linux/linux/net/ipv4/tcp_ipv4.c.html
Hover on any variable :
 - during the fade-in animation, the text in the popup is using subpixel AA
 - after the animation, it's in grayscale AA (unless the final opacity is changed to 1.0), and the hinting is still the same
In this case, if the hinting changed after the animation, it would perhaps be weird, but losing the subpixel AA is already visible.
Added "User Story" to get latest broken places without searching and duped few bugs about same issue.
User Story: (updated)
Depends on: 630879
Depends on: 1095954
Depends on: 977281
Depends on: 1096012
Depends on: 1096546
Depends on: 1102444
Depends on: 659213
Keywords: meta
Most of these issues in these bugs are the same thing and duplicates one of another,
there is no need to reopen them and make this bug as meta,
especially when bug #1303570 fixed all of them.

Care to explain?
(In reply to Virtual_ManPL [:Virtual] - (ni? me) from comment #38)
> Most of these issues in these bugs are the same thing and duplicates one of
> another,
> there is no need to reopen them and make this bug as meta,
> especially when bug #1303570 fixed all of them.

So you've asked people if the issues reported in those bugs are still reproducible and often enough they said yes. Why are you still assuming that "bug #1303570 fixed all of them"?
Flags: needinfo?(dao+bmo)
Because I also could reproduce issues which reporters had, and all of them were not reproducible in Nightly builds started from (2016-09-30) to (2016-10-04). I also asked reporters if they're sill having problems due to courtesy.

So finally care to explain why you do that? As you only replied to my question with another question.

I just wanted to clean a little. Not starting argument war.
Flags: needinfo?(dao+bmo)
If the reporter still sees the problem (like Elbart apparently does in a couple of bugs I looked at) and you don't, it's quite possible that you missed something or that there's some other factor involved. You can't just assume everybody else doesn't know what they're doing.
Flags: needinfo?(dao+bmo)
I never assumed that everybody else doesn't know what they're doing.
About Elbart, he probably didn't even test these Nightly builds which contained the fix, that's why I waited some time for this person about:support to confirm my conjecture, unfortunately without reply.
If you don't get a conclusive response from the reporter, it's probably best to leave the bug open, or at least clearly document how you verified that it's fixed.

As for this bug, it remains to be seen whether someone will be able to do something useful with it. Usually small and focused bugs are more actionable than catch-all bugs. Marking old bugs that are still valid as duplicates of this one seems like a bad idea to me.
(In reply to Dão Gottwald [:dao] from comment #43)
> If you don't get a conclusive response from the reporter, it's probably best
> to leave the bug open, or at least clearly document how you verified that
> it's fixed.
I'm very sorry, but I was thinking that I already done this by posting in my reply bugs: which fixed the issue, caused a regression again and where again this regression is tracked.

(In reply to Dão Gottwald [:dao] from comment #43)
> As for this bug, it remains to be seen whether someone will be able to do
> something useful with it.
Let's hope so, that these years standing issues will finally get proper attention.

(In reply to Dão Gottwald [:dao] from comment #43)
> Usually small and focused bugs are more actionable than catch-all bugs.
> Marking old bugs that are still valid as duplicates of
> this one seems like a bad idea to me.
You have much more experience, same as power, so let's stay with your way,
but I still have other opinion how to deal with this issue.
It seems to affect more areas now :
 - tooltips
 - search bar
 - tab titles on inactive windows
 - second line in downloads popup
(In reply to Loïc Yhuel from comment #45)
> It seems to affect more areas now :
>  - tooltips
>  - search bar
>  - tab titles on inactive windows
>  - second line in downloads popup

This could be bug #1315568, please see it and report back.
Flags: needinfo?(hwti)
(In reply to Virtual_ManPL [:Virtual] - (ni? me) from comment #46)
> This could be bug #1315568, please see it and report back.

With layers.gpu-process.dev.enabled to false, it's less blurry, but still grayscale AA.
So it's seems to be two different issues (but perhapps the new rendering would look good if "correctly" rendered, either with strong hinting, or with subpixel AA).
Is this any better now that bug 1303570 and bug 1306670 landed in 51?
Flags: needinfo?(virtual)
(In reply to Milan Sreckovic [:milan] from comment #49)
> Is this any better now that bug 1303570
It was better, at least for about 3-4 days, as most (if not all) of the issues and the dependencies here were fixed , but...

(In reply to Milan Sreckovic [:milan] from comment #49)
> and bug 1306670
...but, patches from second bug (bug #1306670) caused this regression issue to reappear again, that's what was this bug about at the beginning

(In reply to Milan Sreckovic [:milan] from comment #49)
> landed in 51?
I'm on Nighlty (Firefox 53), not on Beta (Firefox 51).



So the answer is - nothing changed, issue still exist.
Flags: needinfo?(virtual)
Hi :Milan,
It seems that the issue still exists, can you help shed some light here?
Flags: needinfo?(milan)
So, it seems this and bug 1306670 are clashing around what fixes one or the other.
Assignee: nobody → bas
Flags: needinfo?(milan) → needinfo?(bas)
As far as I can tell. On nightly everything where layout is telling us we -can- do subpixel AA we're doing it successfully. There appear to be some cases (I can't hit them easily), where layout says not all text is over opaque pixels, but not applying subpixel AA there is the right thing to do. There may be a situation where layout is telling us we can't do it but we can, I don't know the layout code for that very well but I've seen certain xul elements mess with it a little bit before. In the screenshot, grayscale antialiasing on the -background- tab is correct, as this text is over a partially transparent theme. Subpixel AA over a transparent surface is -not- allowed. As for the bookmark scrolling, I'm having a little trouble getting enough bookmarks in there to scroll, but most likely we're applying some form of transform causing layout to determine it shouldn't be using subpixel AA, but I'm not sure why that would be.
Flags: needinfo?(bas)
(In reply to Bas Schouten (:bas.schouten) from comment #53)
Grayscale AA would probably be fine if it was associated with strong hinting.

On Windows 10, inactive window tab titles use grayscale AA, even if the tab is opaque.
For the search bar, it probably comes from the horizontal scrolling.
Markus, can you comment on, uhm, comment 53?
Flags: needinfo?(mstange)
Not really - somebody will need to reproduce these conditions locally and then debug why layout is saying that subpixel AA cannot be used. However, I don't really understand what difference using Skia makes here - layout shouldn't come to different conclusions based on the Moz2D backend. Are there cases where we were using subpixel AA before even though Layout told us not to? And how / why are we handling those cases differently in Skia?
Flags: needinfo?(mstange)
I don't think there is any difference with Skia, it's just that the issue is more visible.

Previously I wrote there was an issue with tabs on inactive windows. Perhaps I was wrong, or it's now fixed. The real issue now depends on the title length : if it's short there is subpixel AA, if its too long it's using grayscale AA (perhaps due to the opacity gradient ?).
(In reply to Loïc Yhuel from comment #57)
> The real issue now depends on the title
> length : if it's short there is subpixel AA, if its too long it's using
> grayscale AA (perhaps due to the opacity gradient ?).

FYI - It's bug #1322897
Tracking 53+ for this regression and for ux-consistency.
tracking-firefox53: ? → +
I'm having trouble reconciling this bug.  There is "it's in 52", but we're also tracking for 51.  There is "length of the title matters", but that seems to be tracked in bug 1322897.  Then there is the "we cannot reproduce this", where the definition of "this" may not be agreed upon.
Assignee: bas → nobody
status-firefox51: affected → wontfix
status-firefox52: affected → fix-optional
Assignee: nobody → mstange
This was nominated for 54 tracking, but I think Milan was asking for some clarification in Comment 60. We are about to move to 55, and this has been hanging around since Nightly was in 52. Can someone please take a moment to update this bug regarding whether the issue is still being seen in the latest Nightly? Thanks.
(In reply to Marcia Knous [:marcia - use ni] from comment #61)
> This was nominated for 54 tracking, but I think Milan was asking for some
> clarification in Comment 60. We are about to move to 55, and this has been
> hanging around since Nightly was in 52. Can someone please take a moment to
> update this bug regarding whether the issue is still being seen in the
> latest Nightly? Thanks.

Yes.
Unfortunately the issue didn't magically vanish and still remains. ;)
If someone can't reproduce something in this bug, just ni? me and I will explain in detail STR if needed.
(In reply to Virtual_ManPL [:Virtual] - (please needinfo? me) from comment #62)
> (In reply to Marcia Knous [:marcia - use ni] from comment #61)
> > This was nominated for 54 tracking, but I think Milan was asking for some
> > clarification in Comment 60. We are about to move to 55, and this has been
> > hanging around since Nightly was in 52. Can someone please take a moment to
> > update this bug regarding whether the issue is still being seen in the
> > latest Nightly? Thanks.
> 
> Yes.
> Unfortunately the issue didn't magically vanish and still remains. ;)
> If someone can't reproduce something in this bug, just ni? me and I will
> explain in detail STR if needed.

I think it would be helpful to revisit exact STR so that Markus can have them, in order to see if we can move this bug along.
Flags: needinfo?(Virtual)
(In reply to Marcia Knous [:marcia - use ni] from comment #64)
> I think it would be helpful to revisit exact STR so that Markus can have
> them, in order to see if we can move this bug along.

Sure. In the next week or two, I will update "User Story" and "Attachments" with detailed STR.
Flags: needinfo?(Virtual)
See Also: → 1349498
Track 54+ as regression.
tracking-firefox54: ? → +
(In reply to Virtual_ManPL [:Virtual] - (please needinfo? me - so I will see your comment/reply/question/etc.) from comment #65)
> (In reply to Marcia Knous [:marcia - use ni] from comment #64)
> > I think it would be helpful to revisit exact STR so that Markus can have
> > them, in order to see if we can move this bug along.
> 
> Sure. In the next week or two, I will update "User Story" and "Attachments"
> with detailed STR.

Hello Virtual_ManPL - I cannot tell if the User story was updated, but if looks from the bug history if it was not. I am pretty sure this bug will remain stalled until we get a set of STR.
I'm kinda getting more and more busy lately, but looking on it with speedy glance, I think that everything could be easily reproduced by looking on "User Story" and "Attachments". I updated "User Story" with STR and on which system and on which Firefox version this bug is reproducible for sure.
User Story: (updated)
Flags: needinfo?(Virtual)
Thank you! I hope I'll finally get to this this week.
(In reply to Markus Stange [:mstange] from comment #69)
> Thank you! I hope I'll finally get to this this week.

adding ni? in case this got lost :)
Flags: needinfo?(mstange)
Text in omnibox dropdown is affected too, but I didn't figure the exact conditions.
It looks like the search bar : once it has switched to grayscale AA, it will stay and affect all tabs of the window, but not other windows.
url bar has the issue too (but not on all my windows) : grayscale AA when it doesn't have the focus
Depends on: 1366405
The PushGroupAndCopyBackground call I added in bug 1305259 isn't doing anything because the DrawTarget is not opaque and doesn't know anything about opaque subregions.

The former is very easy to fix on Windows 10 by fixing bug 1366405.
But on Windows 7, where we are actually using glass, we can't make the whole layer opaque. So we need some way of carrying along information about opaque regions in the layer until the time where we have the DrawTarget that's used for drawing into the layer, so that we can then set a part of the layer's opaque region as the DrawTarget's opaque rect.
Flags: needinfo?(mstange)
This has been tagged as a P3. It's unclear whether this is getting fixed anytime soon. I am going to tracking "-" it. If and when we fix it, please nominate for uplift to Beta if deemed a low risk fix. Thanks!
tracking-firefox55: + → -
tracking-firefox56: ? → -
Looks like this is complicated, has a bunch of related or dependent bugs, and is not a top priority.  
We can take patches in nightly if anyone is able to work on these font/cleartype issues.
status-firefox60: affected → wontfix
status-firefox61: affected → wontfix
status-firefox62: affected → fix-optional
Too late to fix in 63. We could still take a patch for 65 and potentially for 64.
status-firefox63: affected → wontfix
status-firefox64: affected → fix-optional
Summary: Grayscale antialiasing instead of subpixel antialiasing is still used in some places on Mozilla Firefox Nightly 52.0a1 (2016-10-05) → [meta] Grayscale antialiasing instead of subpixel antialiasing is still used in some places on Mozilla Firefox Nightly 52.0a1 (2016-10-05)

Bulk change for all regression bugs with status-firefox67 as 'fix-optional' to be marked 'affected' for status-firefox68.

status-firefox68: --- → affected

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Severity: critical → --
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: