923542 - Transparency on mouse-over with Azure content

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[anshin]

Attachment: screencast displaying the issue

When I mouse-over the Menu and Downloads panels in Firefox, items become transparent. I only noticed this after the most recent build, and it doesn't happen with `gfx.content.azure.enabled` set to false.

The graphics section of my about:support: http://i.wonoes.com/9ug3jvx4p.png

A screencast showcasing the issue: http://i.wonoes.com/hacgb8s7j.gif

Comment 3

[Fabien Cazenave [:kaze]]

I confirm the bug:
 • it happens on my Linux box too (Ubuntu 12.04 LTS + i3-wm);
 • it doesn’t happen when `gfx.content.azure.enabled' is set to `false' in about:config;
 • it’s also been reported on other minimalistic Linux desktops, see bug 925322 for more details (and more screenshots).

Paul also mentioned in bug 925322 comment 5 that it’s probably caused by bug 916034.

Comment 4

[Fabien Cazenave [:kaze]]

FTR, here’s my graphic configuration:

Adapter Description: Tungsten Graphics, Inc -- Mesa DRI Intel(R) Sandybridge Mobile
Device ID: Mesa DRI Intel(R) Sandybridge Mobile
Driver Version: 3.0 Mesa 8.0.4
GPU Accelerated Windows: 0/3 Basic
Vendor ID: Tungsten Graphics, Inc
WebGL Renderer: Tungsten Graphics, Inc -- Mesa DRI Intel(R) Sandybridge Mobile
windowLayerManagerRemote: false
AzureCanvasBackend: cairo
AzureContentBackend: cairo
AzureFallbackCanvasBackend: none
AzureSkiaAccelerated: 0

Clochix has reported the same bug with this configuration:

Adapter Description: Humper -- Chromium
Device ID: Chromium
Driver Version: 2.1 Chromium 1.9
GPU Accelerated Windows: 0/1 Basic Blocked for your graphics card because of unresolved driver issues.
Vendor ID: Humper
WebGL Renderer: Blocked for your graphics card because of unresolved driver issues.
windowLayerManagerRemote: false
AzureCanvasBackend: cairo
AzureContentBackend: cairo
AzureFallbackCanvasBackend: none
AzureSkiaAccelerated: 0

(not sure it helps, though)

Comment 5

[Fabien Cazenave [:kaze]]

Regression window (thank you Clochix!):
 • works:  http://hg.mozilla.org/mozilla-central/rev/e3c84e9f2490
 • broken: http://hg.mozilla.org/mozilla-central/rev/aca286bc0013

Comment 6

[Fabien Cazenave [:kaze]]

FTR: Étienne and Vivien (Paris office) have just reported that they can’t reproduce this bug with Unity and Gnome 3, respectively.

Comment 7

[Matt Woodrow (:mattwoodrow)]

Attachment: Draw to the correct destination rect

I *think* this is the problem, but I don't have a non-compositing window manager to check.

It seems like a real bug, that would only have an effect when we're invalidating an area that doesn't start at 0,0. It's also in a path that we only take with non-compositing window managers, and transparent windows (popups).

Comment 8

[Matt Woodrow (:mattwoodrow)]

Confirmed that this fixes the issue.

Comment 9

[Octoploid]

Comment on attachment 816388 [details] [diff] [review]
Draw to the correct destination rect

Review of attachment 816388 [details] [diff] [review]:
-----------------------------------------------------------------

It doesn't even compile:
/home/markus/mozilla-central/widget/gtk/nsWindow.cpp:2270:62: error: use of undeclared identifier 'aBoundRect'; did you mean 'aBoundsRect'?
          drawTarget->FillRect(Rect(0, 0, aBoundsRect.width, aBoundRect.height),
                                                             ^~~~~~~~~~
                                                             aBoundsRect
/home/markus/mozilla-central/widget/gtk/nsWindow.cpp:2256:55: note: 'aBoundsRect' declared here
nsWindow::UpdateAlpha(gfxPattern* aPattern, nsIntRect aBoundsRect)
                                                      ^
1 error generated.

Comment 11

[Matt Woodrow (:mattwoodrow)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/85901120533c

Comment 12

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/85901120533c