The default bug view has changed. See this FAQ.

Fx 18 regression: loss of cleartype in portions of content (YouTube video page) after some scrolling

RESOLVED FIXED

Status

()

Core
Graphics: Text
RESOLVED FIXED
4 years ago
7 months ago

People

(Reporter: al_9x, Assigned: mattwoodrow)

Tracking

({regression})

18 Branch
x86
All
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox18+ wontfix, firefox19+ fixed, firefox20 unaffected, firefox21 unaffected, firefox-esr17 unaffected)

Details

Attachments

(4 attachments)

(Reporter)

Description

4 years ago
Created attachment 699655 [details]
grayscale

xp, new profile

http://www.youtube.com/watch?v=SRKf7YLR52Q

it starts normal, after scrolling down, aa goes grayscale
(Reporter)

Comment 1

4 years ago
present in 19.0b1

seems to be gone in 20.0a2 (2013-01-08)
(Reporter)

Updated

4 years ago
Summary: Fx 18 regression: loss of cleartype in portions content (YouTube video page) after some scrolling → Fx 18 regression: loss of cleartype in portions of content (YouTube video page) after some scrolling

Comment 2

4 years ago
confirmed!

windows 7
use hardware acceleration = NO (!)
gfx.font_rendering.cleartype_params.rendering_mode = 2 (!)

on gmail.com ClearType lost colors even without scrolling.
habrahabr.ru/post/107607/ lost colors only after scrolling.

Comment 3

4 years ago
@CoolCmd: could you confirm it's fixed in FF21 as comment #1 claimed, please.
http://nightly.mozilla.org/
Flags: needinfo?(CoolCmd)

Comment 4

4 years ago
(In reply to Loic from comment #3)
Yes, in version 21a1 I don't see this bug.
Flags: needinfo?(CoolCmd)

Updated

4 years ago
Duplicate of this bug: 828241

Updated

4 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

4 years ago
Keywords: regressionwindow-wanted

Comment 6

4 years ago
I first see this in 18.0b4, only with acceleration off.
In 19.0b1, only the scrolling issue occurs, I can't reproduce the Gmail non-scrolling issue.
20.0a2 is fine.

Problem appears in nightly here:
Last good nightly: 2012-12-04
First bad nightly: 2012-12-05

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6fa6e55a93b2&tochange=1942b4d64dc8

Fixed in nightly here:
Last good nightly: 2012-12-11
First bad nightly: 2012-12-12

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4dfe323a663d&tochange=634180132e68

Anyone able to confirm that regression range?
Duplicate of this bug: 828032
Bug 828032 appears to be this same bug on OS X.

Comment 9

4 years ago
For pure entertainment value, go to http://caniuse.com/, give the Search field focus, then scroll the page down just enough to hide the search field… and watch the entire page of text toggle between smoothed and not, every half second. Coincides with the blink rate of the insertion point.

Didn't know if this would help with diagnostics, but it's just too awesome not to share. (Yes, I'm easily entertained.)

Haven't seen this on other pages yet…

Updated

4 years ago
Duplicate of this bug: 829943

Updated

4 years ago
Blocks: 810302
status-firefox18: --- → affected
status-firefox20: --- → unaffected
status-firefox21: --- → unaffected
status-firefox-esr17: --- → unaffected
tracking-firefox18: --- → ?
tracking-firefox19: --- → ?
Keywords: regressionwindow-wanted → regression
OS: Windows XP → All

Comment 11

4 years ago
I can reproduce the problem twitter attachment 701462 [details]  in Firefox18.0 and Firefox 19beta, but not in Aurora20.0a2 and Nightly21.0a1.

Regression window(m-c)
Good:
http://hg.mozilla.org/mozilla-central/rev/6fa6e55a93b2
Mozilla/5.0 (X11; Linux i686; rv:20.0) Gecko/20121204 Firefox/20.0a1 ID:20121204030754
Bad:
http://hg.mozilla.org/mozilla-central/rev/1942b4d64dc8
Mozilla/5.0 (X11; Linux i686; rv:20.0) Gecko/20121205 Firefox/20.0a1 ID:20121205030759
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6fa6e55a93b2&tochange=1942b4d64dc8

Regression window(aurora channel)
Good:
http://hg.mozilla.org/releases/mozilla-aurora/rev/fe20163490ec
Mozilla/5.0 (X11; Linux i686; rv:19.0) Gecko/20121207 Firefox/19.0a2 ID:20121207042017
Bad:
http://hg.mozilla.org/releases/mozilla-aurora/rev/e8c2cb8c583f
Mozilla/5.0 (X11; Linux i686; rv:19.0) Gecko/20121208 Firefox/19.0a2 ID:20121208042017
Pshlog:
http://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?fromchange=fe20163490ec&tochange=e8c2cb8c583f


Regression window(beta channel)
Good:
http://hg.mozilla.org/releases/mozilla-beta/rev/b5fab1c304d2
Mozilla/5.0 (X11; Linux i686; rv:18.0) Gecko/20121207 Firefox/18.0 ID:20121207003552
Bad:
http://hg.mozilla.org/releases/mozilla-beta/rev/4e486ec47f47
Mozilla/5.0 (X11; Linux i686; rv:18.0) Gecko/20121208 Firefox/18.0 ID:20121208005051
Pshlog:
http://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=b5fab1c304d2&tochange=4e486ec47f47

in local build
Last Good: 735426e182ac
First Bad: b64693f63118
Triggered by:
b64693f63118	Matt Woodrow — Bug 810302 - When flattening layers together to avoid component alpha, attempt to pick the 'best' active scrolled root to minimize invalidation during scrolling. r=roc, a=lsblakk


And I also confirmed fixed range in comment#6.

Comment 12

4 years ago
I can confirm the patch of Bug 806099 fixes this problem.
(I applied the patch(https://hg.mozilla.org/mozilla-central/rev/1cc90ffcd6b6) of Bug 806099 to the current 19beta cset 2bb8638b277e, and build in locally)
Depends on: 806099

Updated

4 years ago
Duplicate of this bug: 830052

Updated

4 years ago
Duplicate of this bug: 830054
Matt/Roc - we've seen a lot of duplicates of this bug filed for FF18. The user impact here does not seem severe (and there were no reports pre-release), so we're leaning towards fixing for the first time in FF19. Thoughts on the risk of uplifting bug 806099 to FF18?
Assignee: nobody → matt.woodrow
tracking-firefox19: ? → +

Comment 16

4 years ago
(In reply to Alex Keybl [:akeybl] from comment #15)
> Matt/Roc - we've seen a lot of duplicates of this bug filed for FF18. The
> user impact here does not seem severe (and there were no reports
> pre-release), so we're leaning towards fixing for the first time in FF19.
> Thoughts on the risk of uplifting bug 806099 to FF18?

The impact may not be severe for the average user or those with certain monitor resolutions, but for those of us doing UI design, it's a bit of a PITA. I for one would love to see this fixed soonest.

But I'm not your flavor of developer so I certainly don't know what it will take to nail it. Thanks to all of you for your great work!

Updated

4 years ago
tracking-firefox18: ? → +
(In reply to Alex Keybl [:akeybl] from comment #15)
> Matt/Roc - we've seen a lot of duplicates of this bug filed for FF18. The
> user impact here does not seem severe (and there were no reports
> pre-release), so we're leaning towards fixing for the first time in FF19.
> Thoughts on the risk of uplifting bug 806099 to FF18?

It is not zero-risk, although the patch has been on trunk for a while and no regressions have been reported other than one isolated performance issue.
We should definitely uplift 806099 to beta though. Requested approval over there.

Updated

4 years ago
Duplicate of this bug: 830198

Comment 20

4 years ago
Created attachment 702235 [details]
discrepancy between font display chrome/firefox

Comment 21

4 years ago
Same here.Fonts are very blurry on certain sites (gmail, lequipe.fr) as shown in attachment. Happened since updating to firefox 18. The loss of sharpness is very annoying visually.

Updated

4 years ago
Duplicate of this bug: 830843

Comment 23

4 years ago
Just for you to know, Launchpad has a bug about this particular problem:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1097763

Updated

4 years ago

Updated

4 years ago
status-firefox19: --- → affected
Blocks: 833850
Bug 806099 was uplifted to FF19 on Beta. Should be resolved in that version.
status-firefox18: affected → wontfix
status-firefox19: affected → fixed
Works fine on Firefox 19 beta 4, latest Nightly and Aurora. Can the status be changed to resolved? Or there is something to be added here?

Comment 26

4 years ago
Is it fixed in FF19?

Comment 27

4 years ago
it's fixed

Comment 28

4 years ago
Created attachment 716501 [details]
Scrolling native widgets

It is not totally fixed.
Web pages looks good in FF 19 even after the scrolling; but text inside native widgets does not.
If you edit a long text in a field like the one im writing into and then scroll it; the subpixel antialiasing becomes gray after the scroll and after 2 or 3 seconds it automatically gets RGB antialias.
The same thing happens when i scroll the most viewed sites window with the awesome bar; 3 seconds delay.
If this can help to track the issue, i say that it does NOT happens in the history window.

My system is archlinux 32bit and i'm using firefox 19; see the attached video in a large window/fullscreen carefully.

Comment 29

4 years ago
hi, could my problem be related to this bug: https://bbs.archlinux.org/viewtopic.php?id=156456 ?
It was not present in ff17 but is present in ff18 and is still in ff19. It's really weird...

Comment 30

4 years ago
I'm Confirming this using FF19 Final and FF20b1 But I have found that for now it happens only if HW accel is enabled.

Additionally If I Zoom In/Out page (CTRL+Mouse Scroll) page is rendered correctly, looks like only default zoom is affected.

For Now I'm turning of HW Accel.

Haven't tested nightly for now.
As reference to Above archlinux page I'm using ATi HD 4890 and latest ATi Legacy Drivers 13.1

Comment 31

4 years ago
As peke said in comment #30: It's fixed in Firefox 19 (thanks!) but it can still happen when using hardware acceleration.

I turned on layers.acceleration.force-enabled today (Firefox 20 / Ubuntu 12.10 64-bit / nvidia 310.14) and started noticing the issue again.

I can see it clearly in gmail, and the strange thing is, that it's temporary: font hinting is strange when scrolling, and after you stop, in 2-3 seconds it jumps to being ok. I'm now attempting to record a screencast to show this.

Comment 32

4 years ago
Ah, my bad! No need to screencast, the issue is exactly what kokoko3k said in comment #28, but it doesn't need to be on a native widget (I see it on gmail).

Comment 33

4 years ago
I filed a bugreport for comment #29 https://bugzilla.mozilla.org/show_bug.cgi?id=847962
I don't know, maybe it's related..

Comment 34

4 years ago
@Comment #33: I'm not sure, I just tried to reproduce your issue and couldn't.
Have you tried it on another machine, just to be sure?

Comment 35

4 years ago
I did, it happens on both of my computers and even on Windows 7 (but isn't always *that* noticible). But maybe we should discuss this in the appropriate bugreport :)

Comment 36

4 years ago
Just note to my comment #30 that after upgrading to ATi Radeon HD 7950 and normal 13.1 driver I have no issues anymore, also FF version now is 19.0.2 will keep if issue reacure
(Assignee)

Comment 37

4 years ago
This bug refers to an issue that could only occur *without* hardware acceleration.

Hardware acceleration is currently incomplete on linux, and is disabled by default for all users.

You're probably seeing bug 777170, which is because the component alpha (sub-pixel alpha text) support isn't completed.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED

Comment 38

9 months ago
Firefox 48b5 showes the mentioned behaviour again, while it had been fixed before.
For me the bug manifests in "strange" antialising appalied to GMail's red "Inbox" text label.

On my system I use:
AzureCanvasAccelerated	1
AzureCanvasBackend	skia
AzureContentBackend	cairo
AzureFallbackCanvasBackend	none
CairoUseXRender	0

Comment 39

9 months ago
Created attachment 8767775 [details]
subpixel antialiasing issue with gmails red text
No longer blocks: 833850
You need to log in before you can comment on or make changes to this bug.