677144 - bad cleartype anti-aliasing (white on black text does not look white), ok in Fx 3.6

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[al_9x]

Attachment: Fx 3.6 vs. Fx 4-8

anti-aliasing is sub-pixel, not grayscale, but the colors are off, so the text doesn't look white.  Ok in 3.6.

Comment 1

[al_9x]

Attachment: ufc.com example

Here's another example:

1. http://www.ufc.com/event/UFC134
2. make sure flash loads
3. drop down any sub-menu from the red menu bar (e.g. Games)
4. cleartype colors are off on the smaller font white text (e.g Community), the white text looks yellowish/greenish
5. if flash is disabled, problem does not manifest
6. Fx 3.6 does not have this problem (with or without flash)

Comment 2

[al_9x]

Attachment: third example - http://forums.sinsofasolarempire.com/

Why is this unconfirmed?

Comment 3

[al_9x]

Attachment: 4th example - black Google menu/tool bar on Google image search

do a google image search
e.g. http://www.google.com/search?tbm=isch&q=mozilla

the cleartype on the white text on black Google bar at the top is wrong

if the window height is adjusted to show only the search box, problem goes away

What is the issue with confirming this, how many examples do you need?

Comment 4

[al_9x]

Happens also with acceleration enabled:
GPU Accelerated Windows: 2/2 Direct3D 9

Comment 5

[al_9x]

Attachment: bad cleartype in the urlbar

This is now spreading into chrome, previous examples were in content. This is selected white on blue text in the urlbar. 10.0a1 (2011-10-19), new profile

Comment 6

[Bas Schouten (:bas.schouten)]

(In reply to al_9x from comment #5)
> Created attachment 568258 [details]
> bad cleartype in the urlbar
> 
> This is now spreading into chrome, previous examples were in content. This
> is selected white on blue text in the urlbar. 10.0a1 (2011-10-19), new
> profile

Why is one worse than the other? This might be easier to see with a none-zoomed in one.

This looks like a difference in gamma correction. I suspect something happened to the UI to make the URL bar be put on an additional group or something, changing the gamma correction somewhat.

Comment 7

[al_9x]

(In reply to Bas Schouten (:bas) from comment #6)
> (In reply to al_9x from comment #5)
> > Created attachment 568258 [details]
> > bad cleartype in the urlbar
> > 
> > This is now spreading into chrome, previous examples were in content. This
> > is selected white on blue text in the urlbar. 10.0a1 (2011-10-19), new
> > profile
> 
> Why is one worse than the other? This might be easier to see with a
> none-zoomed in one.

The first (upper) is normal default cleartype, same as in all other apps including prior Fx versions - that's what it's supposed to look like.  The text looks white and very distinct/legible.

The cleartype colors are off in the second one, a little darker, the text looks less white (blueish), less distinct.

Comment 8

[al_9x]

Since the chrome issue is new, here's the regression window:

Last good nightly: 2011-10-10
First bad nightly: 2011-10-11

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e9c620a5c85f&tochange=ccea01542d0b

Comment 9

[al_9x]

(In reply to al_9x from comment #8)
> Since the chrome issue is new, here's the regression window:
> 
> Last good nightly: 2011-10-10
> First bad nightly: 2011-10-11
> 
> Pushlog:
> http://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=e9c620a5c85f&tochange=ccea01542d0b

would someone please confirm and investigate this

Comment 10

[al_9x]

Attachment: youtube playlist

play any YouTube playlist
e.g. http://www.youtube.com/watch?v=sSv9QDCBdKs&list=PLFA63C06680A1C6B5
The difference is particularly glaring in the "next video" text, but is also present in the "now playing" text

considering that displaying text is still the primary function of the browser, why is this bug being ignored?

Comment 11

[LegNeato]

The following information will help:

1. Your graphics section from about:support

2. You platform / OS version (SP3? etc)

3. Your cleartype / AA settings from windows

4. If the examples looks similar on other browsers

5. Any modified preferences from about:support you think are relevant

6. Use http://harthur.github.com/mozregression/ to nail down the actual change that caused the behavior change

7. If this is a laptop, if the problem is the same with the internal panel and an external screen

Also, please make sure your graphics drivers are up to date. If not, update them and see if the issue persists.

Finally, there are lots of bugs in Bugzilla. Please note each user has their own view on the severity of certain bugs. It was good to send a post to the mailing list pointing to this, but it really doesn't make people want to grab it and dig when act abrasively. Please read https://bugzilla.mozilla.org/page.cgi?id=etiquette.html, specifically #1.2

I appreciate you taking the time to file a bug and attach examples, it helps the project and increases the likelihood of a fix.

Comment 12

[al_9x]

(In reply to Christian Legnitto [:LegNeato] from comment #11)

There are two relates issues/symptoms, the older in content (let's take Comment 10 as a representative) and the newer in chrome (Comment 5, Comment 8)


> The following information will help:
> 
> 1. Your graphics section from about:support

driver does not matter, reproducible on NV 6200 (0221) with latest drivers and acceleration on or off, as well as in a vmware vm

Adapter Description VMware SVGA II
Vendor ID 15ad
Device ID 0405
Adapter RAM Unknown
Adapter Drivers vmx_fbDriver
Version 11.6.0.38
Driver Date 7-2-2011
Direct2D Enabled Blocked on your graphics card because of unresolved driver issues.
DirectWrite Enabled false (0.0.0.0, font cache n/a)
WebGL Renderer (WebGL unavailable)
GPU Accelerated Windows 0/1

> 
> 2. You platform / OS version (SP3? etc)

xp sp3

> 
> 3. Your cleartype / AA settings from windows

use cleartype, the hidden cleartype params are at defaults

> 
> 4. If the examples looks similar on other browsers
> 

Why do other browsers matter, this is a regression against Fx, the other (working) browsers are Fx 3.6.24 for the content issue, and 2011-10-10 nightly for the chrome issue.  But if you insist, Chrome 15 looks fine (same as Fx 3.6)

> 5. Any modified preferences from about:support you think are relevant
> 
new profile

> 6. Use http://harthur.github.com/mozregression/ to nail down the actual
> change that caused the behavior change

I've done it for the newer chrome issue (Comment 8), will do it for the content issue.

> 
> 7. If this is a laptop, if the problem is the same with the internal panel
> and an external screen

desktop

Comment 13

[al_9x]

As was explained to me by Jonathan Kew, there are three layout/rendering 
paths on xp, harfbuzz, uniscribe, direct gdi.  There are two prefs in Fx to 
force any one of these paths:

gfx.font_rendering.harfbuzz.scripts
browser.display.auto_quality_min_font_size

1. By default harfbuzz is used - bug manifests
2. harfbuzz.scripts==0 && auto_quality_min_font_size==0, forces uniscribe - 
bug manifests
3. harfbuzz.scripts==0 && auto_quality_min_font_size==<large number>, forces 
direct GDI - bug manifests

Fx 3.6 uses uniscribe and gdi on xp.  I don't know what drawing api harfbuzz 
uses deep down on xp  (if anyone knows please answer), but certainly 
uniscribe and gdi rendering with 4+ shouldn't be any worse than uniscribe 
and gdi rendering with 3.6.  I suspect harfbuzz is not to blame either.

Comment 14

[al_9x]

(In reply to al_9x from comment #13)
> I suspect harfbuzz is not to blame either.

Since all three paths fail, the bug must higher up in the layout/rendering 
stack.

Comment 15

[Ed Morley [:emorley]]

To help you find a more precise regression range, I've sent two changesets from within the comment 8 range to try, to get some interim builds created.

built from 788fb79040ed
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-01bc95217392

built from aee2bf4eb5f8
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-ac72047ce2b5

(The builds will take a few hours to appear and will 404 until then)

If you could try both of these and let me know how you get on, I'll make some more builds to bisect further.

Comment 16

[Jonathan Kew [:jfkthame]]

(In reply to al_9x from comment #13)
> As was explained to me by Jonathan Kew, there are three layout/rendering 
> paths on xp, harfbuzz, uniscribe, direct gdi.  There are two prefs in Fx to 
> force any one of these paths:
> 
> gfx.font_rendering.harfbuzz.scripts
> browser.display.auto_quality_min_font_size
> 
> 1. By default harfbuzz is used - bug manifests
> 2. harfbuzz.scripts==0 && auto_quality_min_font_size==0, forces uniscribe - 
> bug manifests
> 3. harfbuzz.scripts==0 && auto_quality_min_font_size==<large number>, forces 
> direct GDI - bug manifests
> 
> Fx 3.6 uses uniscribe and gdi on xp.  I don't know what drawing api harfbuzz 
> uses deep down on xp  (if anyone knows please answer), but certainly 
> uniscribe and gdi rendering with 4+ shouldn't be any worse than uniscribe 
> and gdi rendering with 3.6.  I suspect harfbuzz is not to blame either.

The issue of harfbuzz/uniscribe/gdi text layout is unlikely to be relevant here. Regardless of the shaping/layout path, the actual glyph rasterization is the same: the glyphs are ultimately drawn by GDI.

What's more likely to affect glyph appearance would be issues hardware acceleration, layers and compositing, etc.; I'm not very familiar how all this works on XP, where newer technologies such as Direct2D are not present.

Comment 17

[Dão Gottwald [:dao]]

Win XP uses D3D9 layers when possible. al_9x said earlier that this happens with and without accelerated layers.

Comment 18

[al_9x]

In reply to Ed Morley [:edmorley] from comment #15)
> To help you find a more precise regression range, I've sent two changesets
> from within the comment 8 range to try, to get some interim builds created.
> 
> built from 788fb79040ed
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-
> 01bc95217392
> 
> built from aee2bf4eb5f8
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-
> ac72047ce2b5
> 
> (The builds will take a few hours to appear and will 404 until then)
> 
> If you could try both of these and let me know how you get on, I'll make
> some more builds to bisect further.

both are good

Comment 19

[Ed Morley [:emorley]]

Thanks :-)

New range:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=788fb79040ed&tochange=ccea01542d0b

built from 29c1738d7e27
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-61279b0026a1

built from 68b7ba483004
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-f3076d02e59f

(I've picked before/after the most likely suspects, so hopefully the new range after this will be sufficient to pick the cause without further builds)

Comment 20

[al_9x]

(In reply to Ed Morley [:edmorley] from comment #19)
> Thanks :-)
> 
> New range:
> http://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=788fb79040ed&tochange=ccea01542d0b
> 
> built from 29c1738d7e27
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-
> 61279b0026a1
> 
> built from 68b7ba483004
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-
> f3076d02e59f
> 
> (I've picked before/after the most likely suspects, so hopefully the new
> range after this will be sufficient to pick the cause without further builds)

both bad

Comment 21

[Ed Morley [:emorley]]

New range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=788fb79040ed&tochange=68b7ba483004

(however the pushlog can't narrow down inside a push, even if put in the URL, so when looking at that page, ignore anything above 68b7ba483004)

built from e1927273c6c9
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-c65ca5f62815

built from 2a151eaf035b
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-a809619a7095

Comment 22

[al_9x]

(In reply to Ed Morley [:edmorley] from comment #21)
> 
> built from e1927273c6c9
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-
> c65ca5f62815

bad

> 
> built from 2a151eaf035b
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-
> a809619a7095

good

Comment 23

[Ben Bucksch (:BenB)]

xref bug 657840 and bug 701812

Comment 24

[Ben Bucksch (:BenB)]

> xref bug 657840

typo: bug 675840

Comment 25

[al_9x]

@edmorley - is the search finished?

Comment 26

[Timothy Nikkel (:tnikkel)]

(In reply to al_9x from comment #25)
> @edmorley - is the search finished?

Not quite, but it looks that most likely it is caused by http://hg.mozilla.org/mozilla-central/rev/e1927273c6c9 bug 682534.

Comment 27

[Ed Morley [:emorley]]

(In reply to al_9x from comment #25)
> @edmorley - is the search finished?

Sorry for the delay, have been playing catchup since the MozCamp event last weekend.

To confirm that http://hg.mozilla.org/mozilla-central/rev/e1927273c6c9 / bug 682534 is to blame (as strange as it will be...), I've pushed the changeset immediately prior to it (http://hg.mozilla.org/mozilla-central/rev/4d61f3ed73b9) to try. 

As before, please give it a go once the builds appear and let us know how you got on:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-4df0f689a4ab

Thanks :-)

Comment 28

[al_9x]

(In reply to Ed Morley [:edmorley] from comment #27)
> As before, please give it a go once the builds appear and let us know how
> you got on:
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-
> 4df0f689a4ab

good

Comment 29

[Ed Morley [:emorley]]

Thanks, this means that http://hg.mozilla.org/mozilla-central/rev/e1927273c6c9 is to blame (somehow?!).

Dao, any ideas?

Comment 30

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Maybe it broke our code that determines whether URL bar text is over an opaque background

Comment 31

[John Daggett (:jtd)]

(In reply to Timothy Nikkel (:tn) from comment #26)
> (In reply to al_9x from comment #25)
> > @edmorley - is the search finished?
> 
> Not quite, but it looks that most likely it is caused by
> http://hg.mozilla.org/mozilla-central/rev/e1927273c6c9 bug 682534.

I don't quite fully understand the logic involved in that patch but I notice that it appears to be playing around with the opacity of the urlbar.  If the opacity of the URL bar is not *precisely* a different rendering codepath will be used, one that doesn't involve subpixel AA (i.e. it will look more washed out in lots of situations).  Not sure why that would affect content though...

Comment 32

[al_9x]

(In reply to John Daggett (:jtd) from comment #31)
> If the
> opacity of the URL bar is not *precisely* a different rendering codepath
> will be used, one that doesn't involve subpixel AA (i.e. it will look more
> washed out in lots of situations).

The issue with urlbar is not the absence of cleartype (grayscale AA), but bad cleartype colors, gamma shifted, presumably.

> Not sure why that would affect content
> though...

It doesn't, the content problem predates this, I lumped the two together because the symptoms were identical, bad cleartype colors in light on dark text,  but the more recent chrome problem should perhaps be split off into a separate bug, unless it turns out both can be fixed at a deeper level where they may intersect.

Comment 33

[al_9x]

Attachment: new imdb player

Here's another content example, from the new floating popup (doesn't navigate) imdb flash player.

Comment 34

[Dão Gottwald [:dao]]

(In reply to Ed Morley [:edmorley] from comment #29)
> Thanks, this means that
> http://hg.mozilla.org/mozilla-central/rev/e1927273c6c9 is to blame
> (somehow?!).

Not for the regression from 3.6 that this bug is really about...

> Dao, any ideas?

That bug applied an SVG mask to the location bar, which presumably triggers this.

Comment 35

[Ed Morley [:emorley]]

Ah, al_9x I didn't realise you were talking about different symptoms for the regression-range we found using the try builds, please can you break that out into another bug please :-)

Comment 36

[al_9x]

Are there plans to deal with these cleartype regressions?

Comment 37

[al_9x]

What is the problem here?  Rapid releases were supposed to provide an opportunity to eliminate regressions not just accumulate them.

There is no good reason why Fx >= 4.0 should not render text on xp as well as 3.6 did.  Why is it acceptable to accumulate these regressions?

Every time I see this badly a-aliased text, I want to reach for another browser.  This is how you lose casual users to Chrome, introducing annoying regressions and ignoring them.

Comment 38

[John Daggett (:jtd)]

Attachment: comparison of chrome/ff3.6/nightly with cleartype on xp

Comparison of chrome / ff 3.6.25 / latest nightly with Arial 12/14px, black bg, white fg

http://people.mozilla.org/~jdaggett/tests/cleartype-waterfall.html

Comment 39

[John Daggett (:jtd)]

al_9x: I think there are probably a number of factors at play here.  Just so that we can eliminate something specific to the drivers on your machine, could you try the testcase below and note whether you see differences between ff3.6 rendering versus the rendering in ff9 or a nightly?

  http://people.mozilla.org/~jdaggett/tests/cleartype-waterfall.html

To get white text / black background, enter 'b' six times (background will change to black) and 'c' once (text changes to white).  Do you see differences with Arial 12/14px?  With any other font?

My guess is you won't but it would be good to eliminate lower-level driver differences as the cause/factor.  On my machine, I don't see differences between ff3.6/nightly.  The way Flash seems to affect rendering behavior makes me suspect something else is causing this.

I'll try testing with some of your other examples.

Comment 40

[al_9x]

(In reply to John Daggett (:jtd) from comment #39)
> al_9x: I think there are probably a number of factors at play here.  Just so
> that we can eliminate something specific to the drivers on your machine

all diagnostics have been done already, read the bug, this has nothing to do with drivers

from comment #12
> 
> driver does not matter, reproducible on NV 6200 (0221) with latest drivers
> and acceleration on or off, as well as in a vmware vm
> 

You have all the info you need to repro this:

xp sp3 (virtual or physical), enable cleartype, digital panel, multiple examples (only one has to do with flash)

The most noticeable case I think is the youtube, load any playlist (flash can be disabled)
http://www.youtube.com/watch?v=LWiuUC9RDhY&list=PL57B5303A505F9DA0&feature=plpp_play_all
and hover over the next video button

and the urlbar issue has already been nailed down to a specific commit.

Comment 41

[John Daggett (:jtd)]

Attachment: testcase, yahoo video playlist bar

Comment 42

[John Daggett (:jtd)]

Attachment: next video text, comparison of ff3.6 vs. nightly

FF 3.6.25 top, Nightly bottom

I see a small difference in the pixel values.

Comment 43

[John Daggett (:jtd)]

(In reply to al_9x from comment #40)

al_9x, we need to come up with a testcase that exhibits what you're seeing.

> The most noticeable case I think is the youtube, load any playlist (flash
> can be disabled)
> http://www.youtube.com/
> watch?v=LWiuUC9RDhY&list=PL57B5303A505F9DA0&feature=plpp_play_all
> and hover over the next video button

Does the attached testcase show the difference on your machine?  That is, 3.6
draws fine, FF9 draws with Cleartype rendering that's slightly darker?

Comment 44

[John Daggett (:jtd)]

Attachment: screenshot, google image search, chrome vs. ff-nightly on xp

I'm not seeing the differences noted in comment 3 for Google image search.  Pixel value differences are tiny in this case (i.e. off by one).

Comment 45

[al_9x]

If you wait long enough all the examples will rot.

Your test case does not repro the problem, my examples are noticeable without any zooming and careful inspection needed.  I specifically pointed you to the next video popup in youtube.
 
Here are the ones that still work (xp sp3, Fx 3.6 & nightly):

Comment 1 - flash needed
drop down the Schedule, Fighters or Community menu and look at the text in the rightmost column of the drop-down.  The cleartype colors are noticeably off.

Comment 2
look at the "Recent Posts" section at the bottom, the orange text (most noticeably, but also other text) is off.  Curiously, if you scroll all the way to the bottom the problem disappears, which gives you the chance to toggle between good and bad in the same browser.

Comment 40
disable flash as it's not a factor
http://www.youtube.com/watch?v=LWiuUC9RDhY&list=PL57B5303A505F9DA0&feature=plpp_play_all
The now playing text in the playlist bar in the bottom is slightly off compared to 3.6, but the next video text (hover over the next video button) is way off
here's a screenshot of a different playlist
https://bug677144.bugzilla.mozilla.org/attachment.cgi?id=570520

Comment 33
disable flash
http://www.imdb.com/title/tt1568346/
Watch trailer
the new video player pops up, doesn't navigate away
"Sorry! Looks like we don't have a video format that your browser knows how to play." text is off.

Comment 46

[John Daggett (:jtd)]

Attachment: testcase, youtube next video button

Steps to reproduce:

Windows XP SP3, Cleartype on, latest nightly

1. Open testcase
2. Click in the empty space within the window
3. Hover over the next video button just to the right of 1/2

Result: "Next video: Eric Schmidt at NASA ..." appears.  With a nightly, there's a noticeable coloration to the white text on a black background.

One thing to note here is that on OSX the popup appears with a background gradient but on Win7/XP nightly/3.6 the background is completely black.  Chrome/Win also displays with a background gradient.

Comment 47

[John Daggett (:jtd)]

Root cause here are the changes roc landed for the layers system on 7/15/2010:

good: 2010-07-15 5fda39cd703c
bad:  2010-07-16 96de199027d7

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5fda39cd703c&tochange=96de199027d7

See bug 564991.

Assigning to bas but maybe this needs to be a roc bug.

Comment 48

[John Daggett (:jtd)]

Attachment: sample showing before/after layer changes

Default background is the text in the testcase before the layer system change, hover to see after the layer system change

Comment 49

[Simon Montagu :smontagu]

From my bisecting this was fixed since the range in comment 47 and then regressed again.

The fix was caused by:
changeset:   50585:536ac334d335
user:        Bas Schouten <[e-mail]>
date:        Sat Aug 14 08:34:55 2010 +0200
summary:     Bug 573229: Part 2 - Enable D2D by default on DX 10 hardware. r=jrmuizel

and the regression by:
changeset:   60658:aa14a8d4c97b
user:        Bas Schouten <[e-mail]>
date:        Sun Jan 16 03:30:05 2011 +0100
summary:     Bug 622482 - Part 5: Enable subpixel AA for D2D surfaces that we believe do not need component alpha. r=roc a=blocking-betaN

Comment 50

[Jet Villegas (inactive)]

Thanks, Simon. Can you determine how we hint this case to force the code path to the component alpha case?

Comment 51

[Robert O'Callahan (:roc) (email my personal email if necessary)]

We take the component alpha path because the popup is partially transparent and it contains text.

This issue is almost certainly the component-alpha blender not doing proper gamma correction.

Comment 52

[al_9x]

Attachment: another regression Fx 16.0 vs. 17.0

all knockout documentation example text with the dark brown background is off,
it corrects itself if you select and deselect the text, this is a new regression relative to 16.0

why did work on this bug stop?  Is text rendering at the Fx 3.6 level of quality too much to ask for?

Comment 53

[al_9x]

Attachment: bad cleartype now in chrome menus (14.0 vs latest nightly)

this has regressed more(Fx 18.0, it seems) bad cleartype now in highlighted (light on dark) chrome menu items

1. why is this not getting fixed?
2. why is this continuing to regress?
3. Is text rendering at the Fx 3.6 level of quality too much to ask for?

Comment 54

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Without knowing exactly what those are screenshots of, it's hard to know what's changing here.

This bug is really too general. We need specific bugs on the rendering of specific testcases.

Comment 55

[al_9x]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #54)
> Without knowing exactly what those are screenshots of, it's hard to know
> what's changing here.
> 
> This bug is really too general. We need specific bugs on the rendering of
> specific testcases.

This didn't go anywhere when there was only one or two examples, and now there are too many?

There are three categories:

1. Some are in content (with urls and directions included)
2. one issue is with the selected text in the urlbar (it may be currently masked by Bug 828073 - no cleartype at all in the urlbar)
3. the latest one is in Fx menus, the latest screenshot is of the selected File->New Window menu item.

Why can't you pick one and look into it, say #3?

Comment 56

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Please file a new bug for it with more details. For one thing, I can't find a "New Window" item on Windows 7 that looks anything like yours.

Comment 57

[al_9x]

(In reply to al_9x from comment #55)
>
> 2. one issue is with the selected text in the urlbar (it may be currently
> masked by Bug 828073 - no cleartype at all in the urlbar)

https://bug828073.bugzilla.mozilla.org/attachment.cgi?id=699649

Comment 58

[al_9x]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #56)
> Please file a new bug for it with more details. For one thing, I can't find
> a "New Window" item on Windows 7 that looks anything like yours.

Bug was filed, Jonathan Kew found the regression range, what about a fix?

Comment 59

[Simona Badau, Desktop QA]

Removing the qawanted keyword since the regression range was added in Comments 22 and 26. Please re-add it if anything else is needed from the qa side.

Comment 60

[al_9x]

Attachment: google docs presentation

here's another example as the others are likely no longer working,

Fx 24.1.1
https://docs.google.com/a/tomdale.net/presentation/d/1e0z1pT9JuEh8G5DOtib6XFDHK0GUFtrZrU3IfxJynaA/preview

open the slide popup menu (bottom left)
it opens with bad cleartype, as soon as you scroll, it corrects itself

Comment 61

[Michelle Funches - QA]

This bug has been tagged for regression and or closure.
This is fixed, working in 
Version 	46.0.1
Build ID 	20160502172042
User Agent 	Mozilla/5.0 (Windows NT 5.1; rv:46.0) Gecko/20100101 Firefox/46.0
Closing as Resolved-WFM