Issue metadata
Sign in to add a comment
|
Tooltip corruption in GNOME
Reported by
van...@gmail.com,
Oct 9
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/69.0.3497.81 Chrome/69.0.3497.81 Safari/537.36 Steps to reproduce the problem: This happens sporadically, so can't be reproduced reliably 1. Cause tooltip to be shown under some unknown conditions 2. Move mouse elsewhere What is the expected behavior? Tooltip should disappear What went wrong? Tooltip black box (tooltip background without text, but with the same shape) remains on a screen. The only way to hide this tooltip is to cause another tooltip to be shown. But it works only if you cause it on the same window it "hanged". I.e. when you see corrupted tooltip and switch to another window, no matter how many tooltips are shown, the "black" one doesn't disappear. Did this work before? Yes 37ish Chrome version: 69.0.3497.81 Channel: stable OS Version: Flash Version: This is highly related to issue 381732 : https://bugs.chromium.org/p/chromium/issues/detail?id=381732 The hanging chrome was fixed, so it's kind of less annoying, but the root cause apparently was not fixed. Note to whoever trying to mark it as duplicate. This is issue is not fixed. There's no other OPENED issues regarding this bug!
,
Oct 10
,
Oct 10
vanuan@Thanks for the issue... Unable to reproduce the issue on reported chrome version 69.0.3497.81 and latest chrome 69.0.3497.100 using Ubuntu 14.04 and 17.10. Attaching screen-cast for reference. Steps: --------- 1. Launched reported chrome 2. Navigated to https://www.wikipedia.org/ and https://rozetka.com.ua/ 3. Hovered mouse on all the links and on tabs As we are observed that the Tooltip disappeared when cursor moved to next link/ Tab as per screencast @Reporter: Could you please review the attached screen-shots and confirm if anything being missed here and verify this issue with fresh profile that is not having any extensions and apps or reset all the flags. Let us know whether issue still persists. Could you please upgrade to latest chrome stable 69.0.3497.100, you can download latest chrome builds here:" https://www.chromium.org/getting-involved/dev-channel ". Also check this issue on chrome Beta 70.0.3538.45 (M-70 moving as stable very soon). Let us know whether issue still persists. Thanks.!
,
Oct 10
Yeah, I know that it's hard to reproduce. It's much more frequent in Fedora. I'm looking for suggestions on how to gather debug information. Is there some special combination to be pressed to report current state?
,
Oct 10
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 10
Yeah, another thing I noticed, it seems to correlate with number of opened windows. Here's some information I gathered with tools I had. It looks like Chrome doesn't use GTK tooltips. It uses X11 windows with black background.
,
Oct 11
This issue is very old. And it doesn't seem like anything was done to fix it. Reread the original thread: > ... commit ... seems to resolve the catastrophic failure mode (wait forever for a MapNotify which will never arrive) in the correct way (override-redirect windows will be mapped by the time the next request is processed), but without resolving the fundamental failure of the client's desired map state being out of sync with the server's actual map state. > Given that, and the prevalence of WMs which trip this failure in the wild, I'd suggest doing away with the unmapped-but-created state for override-redirect windows, and destroying the window entirely rather than unmapping it, with a new window being created when it comes time to remap it. And the commit that fixed the crash is this: https://codereview.chromium.org/2057333002 Unfortunately, it only fixes severity, not the cause of this issue. That is it doesn't lead to crash but it still causes black window without text.
,
Oct 11
As per comment #4 and comment #6, Retried the issue on reported chrome version 69.0.3497.81 and latest chrome 69.0.3497.100 using Ubuntu 14.04 and 17.10 and as we are unable to reproduce it. As of now we don't have Fedora to test this. Hence forwarding it to inhouse team for further triaging of the issue. Adding TE-NeedsTriageFromHYD label. Thanks...!
,
Oct 11
Unable to reproduce the issue on fedora 25 as per steps mentioned in the comment #0 & #3 with chrome #69.0.3497.81 and #69.0.3497.100 Since TE doesn't able to reproduce the issue, adding TE-NeedsTriageHelp label for further triage from dev team.
,
Nov 16
** UI Mass triage** We were unable to reproduce this bug. If this bug still reproduces for you, please reopen or file a new issue. Thanks!
,
Nov 19
Hey, how do I reopen? |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by van...@gmail.com
, Oct 9