1105602 - OS X: Rendering glitches in textareas when hardware acceleration is disabled

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[ce]

Attachment: mantis-glitch.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20141126004005

Steps to reproduce:

For some time now (maybe for ever, i can't recall) i have been having issues with reddit and the RES extension — in particular, sitting on one of reddit's link index pages eventually causes Firefox to use 100 to 200% CPU and makes my lap-top's fan go crazy, until i either close the tab or restart the browser.

Anyway, this bug is not about that.

After some trial and error, i discovered that disabling hardware acceleration fixes this problem — no HWA, no fan issues with reddit/RES. So, i've had hardware acceleration disabled — on both of my machines — for a week or two.

However, this has introduced a new problem — when HWA is off, there are some really ugly rendering glitches when typing in textareas. Specifically, moving the cursor around (both arrow navigation and just normal typing) causes Firefox to draw random blue lines all over inside the box. I assume these blue lines are related to the input focus ring, which is also blue by default on OS X, but i'm not positive.

These lines appear in most textareas i've tested with, but other than that they are pretty inconsistent in nature. Sometimes they appear immediately, sometimes it takes a few lines before they show up. Sometimes typing will erase a previous line, sometimes it'll add a new one. Sometimes the lines are horizontal, sometimes they're vertical.

Usually, clicking off the textarea, or scrolling if it's long enough, will clear all of the lines — until i start typing again, at least.

I've attached two screen-shots of the problem in action (one from a Mantis bug tracker, one from reddit).

I have had this happen on two different machines, both running various versions of Firefox Aurora 35 (up to and including the one you'll see at the top of the ticket). The first machine is a 2011 MacBook Air (MacBookAir4,1), and the second one is a 2011 Mac mini (Macmini5,1). Both are currently running OS X 10.10.1.

I don't have my lap-top in front of me, but about:support has this to say about the mini's graphics capabilities:

Device ID	0x 126
GPU Accelerated Windows	1/1 OpenGL (OMTC)
Vendor ID	0x8086
WebGL Renderer	Intel Inc. -- Intel HD Graphics 3000 OpenGL Engine
windowLayerManagerRemote	true
AzureCanvasBackend	quartz
AzureContentBackend	quartz
AzureFallbackCanvasBackend	none
AzureSkiaAccelerated	0

Comment 1

[ce]

Attachment: reddit-glitch.png

Comment 2

[:Gijs (he/him)]

Do these things happen with either Firefox 33 or 34, with HWA turned off? I expect not, which means this is a regression, which means it would be really helpful if you could try running mozregression ( http://mozilla.github.io/mozregression/ ) to narrow down when this broke.

Comment 3

[ce]

Sorry, i meant to try another version but i forgot. The glitches do not appear in Beta 34.

I don't understand how to use mozregression for this bug — disabling hardware acceleration requires me to restart the browser, and i don't see an option in the script that allows me to do that without re-downloading and starting a new profile.

However, i did pull a few nightlies manually and i tested those. The problem seems to have started between 2014-10-03 (which is good) and 2014-10-08 (which has the bug). I hope that's at least partially useful.

Comment 4

[:Gijs (he/him)]

Yes, that's a good start.

Regarding mozregression: you can pass the path to an existing profile which has hardware acceleration disabled, or you could just use Help > Restart with Add-ons Disabled, which also turns of hardware acceleration, and lets you restart the same build while then still letting you tell mozregression the result (there might be a bit of extra spam in the console in which you run mozregression, but it'll work).

Comment 5

[:Gijs (he/him)]

(unfortunately, I can't seem to easily reproduce this myself on my retina mbp, or I'd do the regression hunt myself...)

Comment 6

[:Gijs (he/him)]

[Tracking Requested - why for this release]:
bad graphics regression on mac's basic compositor...

Also, Markus, I don't suppose there's any way this could be related to the native focus painting stuff we implemented for yosemite compat?

Comment 7

[Markus Stange [:mstange]]

It could very well be related.

Comment 8

[ce]

I missed the profile option, that seemed easy enough. Using that i was able to narrow it down to between 2014-10-07 and 2014-10-08.

I couldn't seem to get further than that (in the 'inbound build' portion). Several of the builds it gave me wouldn't launch, so i tried to tell it to skip them, but the script would not accept that input:

14:09.15 LOG: MainThread Bisector INFO Testing inbound build with timestamp 1412712978, revision f992171f
14:10.44 LOG: MainThread Regression Runner INFO Downloading build from: http://inbound-archive.pub.build.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-macosx64/1412712978/firefox-35.0a1.en-US.mac.dmg
===== Downloaded 100% =====
15:05.02 LOG: MainThread Regression Runner INFO Installing nightly
15:44.40 LOG: MainThread mozversion INFO application_buildid: 20141007131618
15:44.40 LOG: MainThread mozversion INFO application_changeset: f992171f26cd
15:44.40 LOG: MainThread mozversion INFO application_display_name: Nightly
15:44.40 LOG: MainThread mozversion INFO application_id: {ec8030f7-c20a-464f-9b0e-13a3a9e97384}
15:44.40 LOG: MainThread mozversion INFO application_name: Firefox
15:44.40 LOG: MainThread mozversion INFO application_repository: https://hg.mozilla.org/integration/mozilla-inbound
15:44.40 LOG: MainThread mozversion INFO application_vendor: Mozilla
15:44.40 LOG: MainThread mozversion INFO application_version: 35.0a1
15:44.40 LOG: MainThread mozversion INFO platform_buildid: 20141007131618
15:44.40 LOG: MainThread mozversion INFO platform_changeset: f992171f26cd
15:44.40 LOG: MainThread mozversion INFO platform_repository: https://hg.mozilla.org/integration/mozilla-inbound
15:44.40 LOG: MainThread mozversion INFO platform_version: 35.0a1
15:44.40 LOG: MainThread Regression Runner INFO Starting nightly (revision: f992171f26cd)
Was this inbound build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', or 'exit' and press Enter): skip
Was this inbound build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', or 'exit' and press Enter): skip
Was this inbound build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', or 'exit' and press Enter): skip
Was this inbound build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', or 'exit' and press Enter): skip
Was this inbound build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', or 'exit' and press Enter): skip
Was this inbound build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', or 'exit' and press Enter): skip
Was this inbound build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', or 'exit' and press Enter):

Comment 9

[Markus Stange [:mstange]]

Thanks, this pins its down to https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9ee9e193fc48&tochange=dd7637cc42d5 , which contains https://hg.mozilla.org/mozilla-central/rev/c28b84a34465 , so this is a regression from bug 846730.

Comment 10

[Lukas Blakk [:lsblakk] use ?needinfo]

Due to holiday schedule we've only two betas left in the 35.0 beta cycle.  Is there a low-risk backout that can be tested and nominated for approval by Monday Dec 22 for consideration in Beta 6?

Comment 11

[Lukas Blakk [:lsblakk] use ?needinfo]

This missed the last viable beta so we have to wontfix for 35.

Comment 12

[Sylvestre Ledru [:Sylvestre]]

Markus, do you have plan for this? It is too late for 36 for such changes.

Comment 13

[Lawrence Mandel [:lmandel] (use needinfo)]

Markus - This regression has been around for a while now. You're currently the assignee. Do you still intend to work on this fix and can you do so in the next two weeks for Firefox 37?

Comment 14

[Markus Stange [:mstange]]

I'll definitely look into it this week. Sorry for ignoring this for so long... I haven't assigned a high priority to this because the vast majority of our Mac users have hardware acceleration enabled.

Comment 15

[Lawrence Mandel [:lmandel] (use needinfo)]

I reviewed this bug with Milan. We agreed that it's not worth tracking as this is a non standard configuration on Mac.

Comment 16

[u279076]

Markus, any update on this bug?

Comment 17

[Markus Stange [:mstange]]

This seems to be fixed. Probably because with hardware acceleration off, we're no longer drawing directly to the window, but instead we're drawing to layers and compositing them with OMTC BasicCompositor these days.