Closed Bug 923542 Opened 6 years ago Closed 6 years ago

Transparency on mouse-over with Azure content

Categories

(Core :: Graphics, defect)

27 Branch
x86_64
Linux
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla27

People

(Reporter: anshin, Unassigned)

References

Details

(Keywords: regression)

Attachments

(2 files)

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
Blocks: 916034
Duplicate of this bug: 923615
Duplicate of this bug: 925322
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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)
FTR: Étienne and Vivien (Paris office) have just reported that they can’t reproduce this bug with Unity and Gnome 3, respectively.
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).
Attachment #816388 - Flags: review?(ajones)
Confirmed that this fixes the issue.
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.
Duplicate of this bug: 925287
Attachment #816388 - Flags: review?(ajones) → review+
https://hg.mozilla.org/mozilla-central/rev/85901120533c
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla27
Duplicate of this bug: 924547
Duplicate of this bug: 924650
You need to log in before you can comment on or make changes to this bug.