Issue metadata
Sign in to add a comment
|
After #438239 (git b354f88) tooltips render incorrectly when chromium is used on a non-compositing window manager (Linux/X11)
Reported by
clopez@igalia.com,
Dec 15 2016
|
||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36 Steps to reproduce the problem: 1. Build chromium on Linux/X11 (default GN args) at #438239 (git b354f88) (or after that). You can also use the following pre-built tarball to reproduce it: https://www.googleapis.com/download/storage/v1/b/chromium-browser-snapshots/o/Linux_x64%2F438448%2Fchrome-linux.zip?generation=1481698124148195&alt=media 2. Open the Chromium browser using an X11 non-compositing window-manager (XFCE for example). (Note: GNOME3/Unity are compositing WMs, so not valid to trigger this bug) 3. Open this test page on the browser: https://people.igalia.com/clopez/crbug/tooltip_x11_noncompositing_wm and move the mouse over the green block What is the expected behavior? Only one tooltip at a time appear. When a new tooltip appears the older ones disappear. What went wrong? The old tooltip don't disappear, instead a tail of tooltip keeps building until it fills the whole screen. It eventually keeps disappearing when a mouse button is clicked. See a video record of the issue: https://people.igalia.com/clopez/crbug/tooltip_x11_noncompositing_wm/tooltip_bug.mp4 Did this work before? Yes 438238 Chrome version: 57.0.2951.2 Channel: dev OS Version: Debian8 X11/XFCE Flash Version: Reverting r438537 (git b354f88) and rebuilding makes the issue go away. Using Debian 8 (Jessie) with XFCE as window manager and NVIDIA (propietary) graphics drivers (Driver Version: 367.44)
,
Dec 15 2016
Looking at the code changed in r438239 this all seems very strange to me. I can make the issue go away by reverting the changes done at content/gpu/gpu_main.cc $ git show b354f88 content/gpu/gpu_main.cc | patch -p1 -R $ .. rebuild .. execute the test again and everything works back as expected. Is not obvious what is going wrong, i did some tests to try to find where the bug is, but couldn't tell.
,
Dec 15 2016
The information about this happening on non-compositing window managers is not accurate. Apparently XFCE window manager (xfwm4) also supports compositing mode. And the issue also happens when I enable that. But If I use compiz as WM, for example executing o a terminal: $ compiz --replace The issue is not longer reproducible.
,
Dec 15 2016
Looks like I've accidentally changed the lifetime of ui::PlatformEventSource() in one of the branches in gpu_main.cc. Sorry about that, I'll put together a fix.
,
Dec 15 2016
I wasn't able to reproduce the bug, but I think https://codereview.chromium.org/2584513002/ should fix it.
,
Dec 15 2016
Yes. Confirmed. That patch fixes the issue :) Thanks!
,
Dec 19 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/82befc59e91e2befbe289ea85b5f35fc9f6505e1 commit 82befc59e91e2befbe289ea85b5f35fc9f6505e1 Author: skyostil <skyostil@chromium.org> Date: Mon Dec 19 13:48:59 2016 gpu: Don't destroy the ui::PlatformEventSource too early This patch fixes a bug introduced by r438239 where the ui::PlatformEventSource was destroyed before entering the GPU message loop. BUG= 674350 Review-Url: https://codereview.chromium.org/2584513002 Cr-Commit-Position: refs/heads/master@{#439465} [modify] https://crrev.com/82befc59e91e2befbe289ea85b5f35fc9f6505e1/content/gpu/gpu_main.cc
,
Dec 19 2016
|
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 Deleted