1015166 - Content in transparent window on Linux doesn't render correctly when shown/hidden

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect)

Description

[Francis]

Attachment: an extension including a minimal reproduction

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/34.0.1847.116 Chrome/34.0.1847.116 Safari/537.36

Steps to reproduce:

create a XUL window containing a <panel> with background-color: transparent, containing a <browser transparent="transparent">.

Inside the browser, load some HTML content which dynamically shows and hides an element via element.style.display = "none" / "";


Actual results:

Depending upon where on the screen the target div is placed, when it is shown part of it is not rendered.

After hiding, sometimes part of the window's background (which was correctly rendering transparent, showing the window behind it) becomes painted black


Expected results:

The background of the window, around the visible elements, where the HTML content is not attempting to render anything, should remain transparent with the windows behind it visible.

The elements that the HTML content is attempting to render should fully render.

Comment 1

[Francis]

Attachment: expected result

Comment 2

[Francis]

Attachment: actual result 1

Comment 3

[Francis]

Attachment: actual result 2

Comment 4

[Francis]

Since I actually use chromium, here's the user agent of the browsers where I've recreated this issue:
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0
Mozilla/5.0 (X11; Linux i686; rv:29.0) Gecko/20100101 Firefox/29.0

Here's the about:support Graphics section

From the Ubuntu machine:
Adapter Description	Intel Open Source Technology Center -- Mesa DRI Intel(R) Sandybridge Mobile
Device ID	Mesa DRI Intel(R) Sandybridge Mobile
Driver Version	3.0 Mesa 9.1.7
GPU Accelerated Windows	0/1 Basic
Vendor ID	Intel Open Source Technology Center
WebGL Renderer	Intel Open Source Technology Center -- Mesa DRI Intel(R) Sandybridge Mobile
windowLayerManagerRemote	false
AzureCanvasBackend	cairo
AzureContentBackend	cairo
AzureFallbackCanvasBackend	none
AzureSkiaAccelerated	0

And the Gentoo machine:
Adapter Description     X.Org -- Gallium 0.4 on AMD PALM
Device ID       Gallium 0.4 on AMD PALM
Driver Version  3.0 Mesa 10.1.0
GPU Accelerated Windows 0/4 Basic
Vendor ID       X.Org
WebGL Renderer  X.Org -- Gallium 0.4 on AMD PALM
windowLayerManagerRemote        false
AzureCanvasBackend      cairo
AzureContentBackend     cairo
AzureFallbackCanvasBackend      none
AzureSkiaAccelerated    0

FWIW, I've reproduced this in the exact same way using the same exact Gentoo build on i915, nvidia (proprietary driver), and AMD (open source driver).

Let me know what other information is needed.

Comment 5

[Francis]

This bug does NOT occur in 26.0. It DOES occur in: 27.0, 27.0.1, 28.0, 29.0.1, and 30.0b6

Comment 6

[Francis]

mozregression --good=2013-09-17 --bad=2013-10-28 --app=firefox --addons=/tmp/\{2d609520-e1c8-11e3-8b68-0800200c9a66\}.xpi

Got as far as we can go bisecting nightlies...
Ensuring we have enough metadata to get a pushlog...
Last good revision: e3c84e9f2490 (2013-10-02)
First bad revision: 0e26e6f12ad9 (2013-10-03)
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e3c84e9f2490&tochange=0e26e6f12ad9

... attempting to bisect inbound builds (starting from previous day, to make sure no inbound revision is missed)
Downloading build from: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013/10/2013-10-01-03-02-04-mozilla-central/firefox-27.0a1.en-US.linux-x86_64.tar.bz2
===== Downloaded 100% =====
Installing nightly
Getting inbound builds between 6b92cb377496 and 0e26e6f12ad9
Oh noes, no (more) inbound revisions :(


I'm getting my machine set up to build so I can bisect further

Comment 7

[Loic]

Does the issue exist on Windows too? I installed your add-on in FF32 on Win 7, but it does nothing.

Comment 8

[Francis]

I believe that it's Linux-specific. I have tried it on Mac and the bug does NOT reproduce, using 29.0.1.

To make the addon do something:
1) add its toolbar button to your menu or toolbar or whatever
2) click the toolbar button, which will open the transparent window
3) click on the "Click me!" div a few times to show/hide the "Lorem ipsum" div

Comment 9

[Loic]

Ok thanks, Step 1) did the trick.
It works fine with FF32 on Win 7, the add-on creates a 2nd window called TransparencyBug and each time I click on the "Click me!" div, it hides/shows the "Lorem ipsum" div.

Comment 10

[Francis]

Attachment: transparency-bug-bisect.log

I've performed a bisect. It ended up in what seems an infinite loop of attempting to build the same broken build over and over, because there are a series of broken builds in the narrow range at the end between the last known good and first known bad commits.

This build failed!
hg -R /home/fferrell/.moz-commitbuilder-cache/mozbuild-trunk bisect --skip
Due to skipped revisions, the first bad revision could be any of:
changeset:   149622:ad70d9583d42
user:        Matt Woodrow <[e-mail]>
date:        Wed Oct 02 22:12:34 2013 +1300
summary:     Bug 916034 - Use a similar surface rather than an image surface for the canvas background cache when using azure. r=ajones

changeset:   149623:2f189d31161d
user:        Matt Woodrow <[e-mail]>
date:        Wed Oct 02 22:12:36 2013 +1300
summary:     Bug 916034 - Enable azure content for gtk2. r=jrmuizel

changeset:   149624:d1d8f1dba4d5
user:        Honza Bambas <[e-mail]>
date:        Wed Oct 02 11:30:42 2013 +0200
summary:     Bug 922123 - Shutdown hang with 100% CPU on Nightly with new cache, r=michal

changeset:   149625:d0f501b227fc
user:        Matt Woodrow <[e-mail]>
date:        Wed Oct 02 22:35:19 2013 +1300
summary:     Bug 916034 - remove + character from a broken rebase. r=bustage

Interestingly, one nearby build which had "DONTBUILD" in the commit message successfully built and ran.

Here's the bisect command I used, after bisecting nightly builds.

 $ mozregression --good=2013-10-02 --bad=2013-10-03 --app=firefox --addons=/home/fferrell/outbox/\{2d609520-e1c8-11e3-8b68-0800200c9a66\}.xpi --persist=/opt/mozilla/
Got as far as we can go bisecting nightlies...
Ensuring we have enough metadata to get a pushlog...
Using local file: /opt/mozilla/2013-10-02--mozilla-central--firefox-27.0a1.en-US.linux-x86_64.tar.bz2
Installing nightly
Using local file: /opt/mozilla/2013-10-03--mozilla-central--firefox-27.0a1.en-US.linux-x86_64.tar.bz2
Installing nightly
Last good revision: e3c84e9f2490 (2013-10-02)
First bad revision: 0e26e6f12ad9 (2013-10-03)
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e3c84e9f2490&tochange=0e26e6f12ad9

... attempting to bisect inbound builds (starting from previous day, to make sure no inbound revision is missed)
Using local file: /opt/mozilla/2013-10-01--mozilla-central--firefox-27.0a1.en-US.linux-x86_64.tar.bz2
Installing nightly
Getting inbound builds between 6b92cb377496 and 0e26e6f12ad9
Oh noes, no (more) inbound revisions :(
do you want to bisect further by fetching the repository and building? (y or n) y
Trunk not found.
Removed old mozbuild-trunk directory. Downloading a fresh repo from mozilla-central...
requesting all changes
adding changesets
adding manifests
adding file changes
added 184678 changesets with 1034818 changes to 158224 files
updating to branch default
95615 files updated, 0 files merged, 0 files removed, 0 files unresolved

 Narrowed changeset range from 6b92cb377496 to 0e26e6f12ad9

Time to do some bisecting and building!
26003 files updated, 0 files merged, 16334 files removed, 0 files unresolved

Testing changeset 149575:96947390e48e (216 changesets remaining, ~7 tests)
908 files updated, 0 files merged, 37 files removed, 0 files unresolved


My build environment wasn't set up, so after I got that sorted out I completed the bisect with: mozcommitbuilder -j 4 -g 6b92cb377496 -b 0e26e6f12ad9

Comment 11

[Francis]

Bug 916034 certainly appears to be closely related. Comment 21 there references bug 924547, duplicate of Bug 923542. The screen cast attached there appears to be a very similar kind of artifact. The difference here is that setting gfx.content.azure.enabled to false, as referenced in the comments there, does NOT cause the problem to go away.

Comment 12

[Francis]

After bisecting around the broken build, I've found the following:

The first bad revision is:
changeset:   149623:2f189d31161d
user:        Matt Woodrow <[e-mail]>
date:        Wed Oct 02 22:12:36 2013 +1300
summary:     Bug 916034 - Enable azure content for gtk2. r=jrmuizel

This commit just turns on a default pref gfx.content.azure.enabled. I'll move further back in history, bisecting with this pref turned on.

Comment 13

[Loic]

CC'ing dev.

Comment 14

[Matt Woodrow (:mattwoodrow)]

Attachment: Account for TopLeft of aBoundsRect

I think this should fix the issue, but I'm not on linux at the moment.

Can you test this to confirm please :)

Thanks for the regression range too!

Comment 15

[Francis]

I didn't finish bisecting today; I was hoping to narrow it down to something more than a pref change. With the pref enabled, mozregression found Sept 20, I think it was. I'm not sure, though, the notes are on another computer.

What build should I apply your patch to? head? 29? If head, do you expect it to apply cleanly and work as desired with 29?

Comment 16

[Francis]

I've never touched firefox internal code, so please correct me if I'm ignorant or out of line. Doesn't the SetTransform() need to be inside the if? I can't conjecture about when drawTarget might be null, but I can only imagine that the if is there on purpose.

Comment 17

[Matt Woodrow (:mattwoodrow)]

(In reply to Francis from comment #15)
> I didn't finish bisecting today; I was hoping to narrow it down to something
> more than a pref change. With the pref enabled, mozregression found Sept 20,
> I think it was. I'm not sure, though, the notes are on another computer.

I suspect that's probably the date the pref started doing something useful. This code has always been broken.

> 
> What build should I apply your patch to? head? 29? If head, do you expect it
> to apply cleanly and work as desired with 29?

I wrote it against trunk, but I think it should apply and work against 29.

(In reply to Francis from comment #16)
> I've never touched firefox internal code, so please correct me if I'm
> ignorant or out of line. Doesn't the SetTransform() need to be inside the
> if? I can't conjecture about when drawTarget might be null, but I can only
> imagine that the if is there on purpose.

Yes, that's a good point. I'll move it down.

Comment 18

[Francis]

(In reply to Matt Woodrow (:mattwoodrow) from comment #17)
> I wrote it against trunk, but I think it should apply and work against 29.

It solves the problem for my attached test case on head. I'll continue testing on 29 with my real use case, as I need to deploy this ASAP.

> Yes, that's a good point. I'll move it down.

I'm testing this only after moving both the construction of transform and the call to SetTransform into the if.

What is standard practice for reviewing patches? Is there an automated test suite I should run?

Comment 19

[Matt Woodrow (:mattwoodrow)]

Attachment: Account for TopLeft of aBoundsRect

Comment 20

[Matt Woodrow (:mattwoodrow)]

(In reply to Francis from comment #18)

> What is standard practice for reviewing patches? Is there an automated test
> suite I should run?

I doubt we have any automated tests that cover this code, otherwise we'd have caught the original regression.

Just confirming that it fixes your issue should be sufficient.

Comment 21

[Francis]

(In reply to Matt Woodrow (:mattwoodrow) from comment #20)
> I doubt we have any automated tests that cover this code, otherwise we'd
> have caught the original regression.
> 
> Just confirming that it fixes your issue should be sufficient.

OK. I was more so thinking about finding regressions from tests for close but unrelated things.

Thank you for providing a patch so quickly. Let me know if there's anything else you need from me.

Comment 22

[Matt Woodrow (:mattwoodrow)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/f6e327f9749c

Comment 23

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/f6e327f9749c