Closed Bug 1224974 Opened 6 years ago Closed 6 years ago
widgets don't paint correctly after mouseovers on GTK with non-compositing WM
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?)
Bas, any ideas why this might be?
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.
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.
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.
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+
Confirmed fixed on 2015-11-25's nightly build.
You need to log in before you can comment on or make changes to this bug.