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.

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.

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

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

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

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

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.

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 <mwoodrow@mozilla.com> 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 <mwoodrow@mozilla.com> 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 <honzab.moz@firemni.cz> 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 <mwoodrow@mozilla.com> 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

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.

After bisecting around the broken build, I've found the following: The first bad revision is: changeset: 149623:2f189d31161d user: Matt Woodrow <mwoodrow@mozilla.com> 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.

CC'ing dev.

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!

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?

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.

(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.

(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?

(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.

(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.