Closed Bug 1224974 Opened 6 years ago Closed 6 years ago

widgets don't paint correctly after mouseovers on GTK with non-compositing WM

Categories

(Core :: Graphics, defect)

x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla45
Tracking Status
firefox45 + fixed

People

(Reporter: froydnj, Assigned: lsalzman)

References

Details

(Keywords: regression, Whiteboard: gfx-noted)

Attachments

(1 file)

STR:

1. Go to any site (I used bugzilla.mozilla.org for an https site and amazon.com for an http site)
2. Click on the circled "i" in the address bar.
3. Move mouse over the ">" button for displaying further information.

Expected result:

The button highlights.

Actual result:

The button completely disappears and one can see the address bar, bookmark bar, etc. beneath it.

Clicking on the button does produce the expected result (information about the security of the page is displayed, etc.), but it's extremely surprising to have it disappear.  I occasionally see the globe icon and the lock icon in the info box disappear when I mouse into the box, but I can't get that to reproduce reliably currently.
I don't see this on Linux in 7cd2d806bd06 (m-c today).
Somewhere in https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=cc473fe5dc512c450634506f68cbacfb40a06a23&tochange=3cc3b1968524248450c465c4ea2ee5596ffa65f2 things go badly wrong for me.  The 11 Nov nightly does not exhibit the problem and the 12 Nov nightly does.
I also see this with the hamburger menu: opening it and mousing over the menu icons cause them to no longer be displayed.
This appears to be the fault of bug 1210560.
Component: General → Graphics
Product: Firefox → Core
[Tracking Requested - why for this release]: Poor Linux user experience (possibly only limited to some versions of GTK?)
Blocks: 1210560
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
Summary: infbox about connection security paints badly → widgets don't paint correctly after mouseovers
Bas, any ideas why this might be?
Flags: needinfo?(bas)
Duplicate of this bug: 1225719
One would think this is a sort of bug in the linux cairo backend or something like that considering it's restricted to linux. I'll ask Lee to take a look at this later today.
Flags: needinfo?(bas)
Keywords: regression
Summary: widgets don't paint correctly after mouseovers → widgets don't paint correctly after mouseovers on GTK with non-compositing WM
Duplicate of this bug: 1225119
Whiteboard: gfx-noted
See Also: → 1226255
I couldn't manage to reproduce this locally.

Can we get some more info on this? Graphics section of about:support, OS/version, and GTK3 version would be helpful to know so we can try to identify any causative factors.
Flags: needinfo?(nfroyd)
about:support graphics:

Adapter Description	X.Org -- Gallium 0.4 on AMD PITCAIRN
Asynchronous Pan/Zoom	wheel input enabled
Device ID	Gallium 0.4 on AMD PITCAIRN
Driver Version	3.0 Mesa 10.3.2
GPU Accelerated Windows	0/4 Basic (OMTC)
Supports Hardware H264 Decoding	No;
Vendor ID	X.Org
WebGL Renderer	X.Org -- Gallium 0.4 on AMD PITCAIRN
windowLayerManagerRemote	true
AzureCanvasBackend	cairo
AzureContentBackend	cairo
AzureFallbackCanvasBackend	none
AzureSkiaAccelerated	0
CairoUseXRender	1

This is Ubuntu 15.04...I think?  Maybe 14.10.

GTK+3 version is 3.12.2-0-ubuntu15.2.

This also happens on a different machine with GTK+3 3.14.5-1+deb8u1.  about:support for that machine:

Adapter Description	VMware, Inc. -- Gallium 0.4 on llvmpipe (LLVM 3.5, 256 bits)
Asynchronous Pan/Zoom	none
Device ID	Gallium 0.4 on llvmpipe (LLVM 3.5, 256 bits)
Driver Version	3.0 Mesa 10.3.2
GPU Accelerated Windows	0/1 Basic (OMTC)
Supports Hardware H264 Decoding	No;
Vendor ID	VMware, Inc.
WebGL Renderer	VMware, Inc. -- Gallium 0.4 on llvmpipe (LLVM 3.5, 256 bits)
windowLayerManagerRemote	true
AzureCanvasBackend	cairo
AzureContentBackend	cairo
AzureFallbackCanvasBackend	none
AzureSkiaAccelerated	0
CairoUseXRender	1

(That one is running over an SSH connection; not sure if that makes any difference.)

Bug 1225719 comment 4 says you need a non-compositing window manager to reproduce.
Flags: needinfo?(nfroyd)
While the initial STR didn't work for me, I did manage to reproduce it via the hamburger menu. Investigating it...
Assignee: nobody → lsalzman
Status: NEW → ASSIGNED
The problem was introduced in a regression in bug 1210560 patch 7 that modified widget/gtk/nsWindow.

nsWindow::UpdateAlpha was rendering into the temporary image buffer at an offset, when it should have just been rendering into it at the origin. This patch fixes that.

I also noticed that the gfxContext constructor doesn't initialize the DrawTarget's matrix with the GetDTTransform() which is necessary to utilize device offset passed in for shaped windows. It was just initializing with identity instead. I changed that to use the DT transform instead now.

There are also some incidental cleanups I batched in here that I did while I was trying to track down the problem.
Attachment #8689750 - Flags: review?(bas)
Comment on attachment 8689750 [details] [diff] [review]
fix GTK shaped window drawing

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

::: gfx/thebes/gfxContext.cpp
@@ +81,5 @@
>  
>    mStateStack.SetLength(1);
>    CurrentState().drawTarget = mDT;
>    CurrentState().deviceOffset = aDeviceOffset;
> +  mDT->SetTransform(GetDTTransform());

Funny how apparently never before anyone used an offset context before changing the transform :-). Nice catch!

::: widget/gtk/nsWindow.cpp
@@ +2232,5 @@
>          // call UpdateTranslucentWindowAlpha once. After we have dropped
>          // support for non-Thebes graphics, UpdateTranslucentWindowAlpha will be
>          // our private interface so we can rework things to avoid this.
>          boundsRect = region.GetBounds();
> +        dt->PushClipRect(Rect(boundsRect));

ooh right.. that works now, nice!
Attachment #8689750 - Flags: review?(bas) → review+
https://hg.mozilla.org/mozilla-central/rev/1ca5537062ab
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla45
Confirmed fixed on 2015-11-25's nightly build.
Duplicate of this bug: 1225197
You need to log in before you can comment on or make changes to this bug.