937567 - Titlebar incorrectly painting background on off-screen page load

Status: RESOLVED INCOMPLETE

(Core :: Graphics, defect)

Description

[Florian Bender]

Attachment: titlebar-background-painting.png

On MBA 2012, OS X 10.9.0

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

Actual: 
The background beneath the website title (and a bit more) has a different (lighter) background than the rest of the titlebar (see attachment for screenshot).

Expected: 
Same background.

STR: 
0. Fx is maximized (not fullscreen) on the first Desktop, Mail is in fullscreen in the next Desktop to the right (single screen config).
1. Open a long-loading bug, e.g. Bug 486918. 
2. IMMEDIATELY swipe the touchpad with four fingers to change the current Desktop to Mail.
3. Wait a reasonable amount of time so you are sure that the page has completely loaded.
4. Return to the Desktop with Firefox (again, swiping). 
5. Compare with screenshot in attachment. 

Works equally well if you open a link e.g. in a bugmail, then immediately switch back to Mail.app (through swipe), wait, and then swipe back to Fx, or if you click on the Firefox icon in the dock to go back to it.


I tried the following (each separately), but that did not change anything: 
– Disable hardware acceleration in settings.
– layers.offmainthreadcomposition.enabled = false
– layers.acceleration.disabled = true

Comment 1

[Florian Bender]

I don't recall this being an issue with earlier versions of Firefox, though I don't know if Fx 24-25 were affected or not. 

Bug 913407 / Bug 902591 appear similar, so setting as See Also. Could be something totally different, though.

Comment 2

[:Gijs (he/him)]

(In reply to Florian Bender from comment #1)
> I don't recall this being an issue with earlier versions of Firefox, though
> I don't know if Fx 24-25 were affected or not. 
> 
> Bug 913407 / Bug 902591 appear similar, so setting as See Also. Could be
> something totally different, though.

Also, bug 941559 ? Maybe try an inbound build, seems that landed recently...

Comment 3

[Florian Bender]

This is still an issue with browser.tabs.drawInTitlebar = false with Australis (this changed for Mac, that's why the pref needs to be flipped since the Australis landing somewhere in Fx 28).

Comment 4

[Florian Bender]

It seems to me that not all parts of the window are repainted when the window is gaining focus, so instead some parts still show the "inactive window" style.

Bug 940668 and Bug 939010 may be related.

Comment 5

[Markus Stange [:mstange]]

I wanted to debug this today but I can't reproduce it now :(

Comment 6

[Florian Bender]

OK, STRs still work on my device (13" MBA 2012, Nightly 29.0a1 (2014-01-31)): 

0. You may need to disable drawInTitlebar in about:config (i.e. set to false).
1. Open Firefox on the first desktop (NOT fullscreen, maximized, though the problem is reproducible with a smaller window). 
2. Open Mail.app in fullscreen mode. 
3. In Firefox, start to load a long-loading page (or simulate a slow network) in foreground. Immediately …
4. Immediately switch to Mail.app with the 4-finger-swipe gesture, and wait …
5. Wait for the page to finish loading (i.e. throbber no longer visible and replaced by favicon) – as you cannot see that, just wait long enough that you are confident the page finished loading. Afterwards …
6. Swipe back to the first desktop where Firefox is and its window becomes focused (don't click anywhere). 

You should now see the title having a different background than the rest of the chrome. 

Now, if you simply switch between the desktops (or fullscreen apps) – you can exhibit that without loading anything, and you control the (speed of the) movement by not lifting your fingers while swiping/scrubbing – you can see that *while* transitioning, the chrome *except* the titlebar is in the unfocused state (i.e. with a light background) until you lift your fingers and the transition completes. I don't know if this is related but it might indicate that painting is different/delayed when Firefox is off screen, and we may benefit from an early repaint when we are relatively certain that the Firefox window comes into view. 

My touch/gesture setup (if this is of any use, for the most part the default settings): 
- enabled tap-to-click
- secondary (= right)click with two-finger-tap
- disabled three-finger-tap lookup gesture
- move windows/objects with three-finger-hold
- natural scrolling, two-finger-pinch zoom, two-finger-double-tap ingelligent zoom, two finger rotate
- page turn with two-finger-horizontal-swipe
- switch (fullscreen) apps with four-finger-horizontal-swipe
- notification center with two-finger-right-edge-swipe
- mission control with four-fingers-upwards-swipe
- exposé with four-fingers-downwards-swipe
- launchpad with three-finger-pinch-gesture
- show desktop with three-finger-reverse-pinch-gesture

Comment 7

[Rob Campbell [:rc] (:robcee)]

Attachment: Screen Shot 2014-03-11 at 11.57.24 AM.png

Another example.

Collapsed Titlebar doesn't draw properly when restarting the browser in background when an HTTP auth dialog prompts.

STR:

1. Open a page requiring http auth, e.g., intranet.mozilla.org
2. restart browser
3. when browser restarts, click another app to defocus firefox
4. wait for the prompt to appear

Expected:

Titlebar gets focused background

actual:

Painting doesn't cover full titlebar. See screenshot.

Comment 8

[Rob Campbell [:rc] (:robcee)]

Addendum:

> STR:
> 
> 1. Open a page requiring http auth, e.g., intranet.mozilla.org

1.5 Open and select a different tab.

> 2. restart browser
> 3. when browser restarts, click another app to defocus firefox
> 4. wait for the prompt to appear

Comment 9

[Rob Campbell [:rc] (:robcee)]

ADB Helper	0.2.1	true	[e-mail]
Adblock Plus	2.5.1	true	{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}
Copy ShortURL	2.1	true	jid0-ODIKJS9b4IT3H1NYlPKr0NDtLuE@jetpack
Firefox OS 1.3 Simulator	7.0pre7.20140113	true	[e-mail]
Firefox OS Simulator	4.0.1	true	[e-mail]
FxIF	0.4.7.1	true	{11483926-db67-4190-91b1-ef20fcec5f33}
Mass Password Reset	1.05	true	[e-mail]
Pocket	3.0.4	true	[e-mail]
Socialite	1.5.1	true	socialite@chromakode
Sort Tabs	1.1	true	[e-mail]
TabCloser	1.07	true	[e-mail]
Tumblr	1.1	true	jid0-505z9sfBXZaQjzjmiUDpPsTKvHo@jetpack
TweetRight	0.43.1	true	jid1-SmvuJ9Cq3Cx13w@jetpack
Twitter Address Bar Search	1	true	[e-mail]
User Agent Switcher	0.7.3	true	{e968fc70-8f95-4ab9-9e79-304de2a71ee1}
WikifyTabs	1.1	true	[e-mail]
Adobe Acrobat - Create PDF	1.2	false	[e-mail]
ColorZilla	2.8	false	{6AC85730-7D0F-4de0-B3FA-21142DD85326}
DOM Inspector	2.0.14	false	[e-mail]
RESTClient

Comment 10

[Ryan VanderMeulen [:RyanVM]]

Do you still see this, Florian?

Comment 11

[Florian Bender]

Just reproduced on MBA 2012, OS X 10.10.5 with Fx 42b5 with the STR in comment 0.

Comment 12

[Ryan VanderMeulen [:RyanVM]]

I don't have a Mac handy myself to test on. Would be willing to try narrowing down a regression range with the mozregression tool? http://mozilla.github.io/mozregression/. Something like |mozregression --bad-release 27| should be enough to get you started and it should only take 15min or so to bisect.

Comment 13

[Ryan VanderMeulen [:RyanVM]]

Paul, can you please try to narrow this down with mozregression?

Comment 14

[Paul Oiegas [:poiegas], PM for (Ecosystem QA, Services QA, WebCompat QA, Hubs QA teams)]

I could not reproduce this issue on iMac on the latest Nightly build 45.0a1. Since this issue was reported on a laptop, we should try to reproduce this on one. Ovidiu, can you please test this, and provide any feedback ?

Comment 15

[ovidiu boca[:Ovidiu]]

Build ID: 20151117030242
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Firefox/45.0

Hi, 
I can't reproduce this problem on Macbook pro retina 10.9.5 on the latest Nightly build 45.0a1(2015-11-17). 
Please if you can, provide more info to try to reproduce this, and also if you will, please test the bug with the latest Nightly, can be downloaded from here: https://nightly.mozilla.org/

Comment 16

[Florian Bender]

Can still reproduce in Fx 45.0a2 (2015-12-23) Dev Edition (Dev Theme disabled, e10s enabled, `browser.tabs.drawInTitlebar` set to false & restarted) like in Comment 11. Will try to pin down the regression range in the coming days (thus not clearing ni? for now).

Comment 17

[ovidiu boca[:Ovidiu]]

> Can still reproduce in Fx 45.0a2 (2015-12-23) Dev Edition (Dev Theme
> disabled, e10s enabled, `browser.tabs.drawInTitlebar` set to false &
> restarted) like in Comment 11. Will try to pin down the regression range in
> the coming days (thus not clearing ni? for now).

Hi Florian, 
Did you manage to pin down the regression range?(In reply to Florian Bender from comment #16)

Comment 18

[u279076]

(In reply to Florian Bender from comment #16)
> Can still reproduce in Fx 45.0a2 (2015-12-23) Dev Edition (Dev Theme
> disabled, e10s enabled, `browser.tabs.drawInTitlebar` set to false &
> restarted) like in Comment 11. Will try to pin down the regression range in
> the coming days (thus not clearing ni? for now).

Florian, it's been over four months. Did you manage to find a regression window? I'm afraid this bug report will need to be closed as incomplete soon without new information.

Comment 19

[u279076]

I am closing this bug as incomplete due to lack of information. Please reopen this bug report if you can reproduce and provide a regression window.