Page MenuHomePhabricator

Yellow tooltips freeze chromium on Arch and E19
Closed, ResolvedPublic

Description

This problem appeared when upgraded to E 0.19.0 and persists since. Oh yes I've got a ton of tabs open but most of them are suspended using The Great Suspender.

So, at random times maybe once an hour a yellow tooltip - either on the web page, on the tab bar or over the add-ons/extensions icons - appears all white and persists there on the screen, even if I hide or move the chromium window and all. At this time browser is still usable but only until the next such tooltip is invoked. It replaces the previous one, persists on the screen and freezes chromium completely.

When running from terminal, no messages appear there when the whole thing happens. Nothing more I can tell. Using OpenGL rendering and some basic AMD graphics card.

jabol240 created this task.Oct 24 2014, 2:58 AM
jabol240 updated the task description. (Show Details)
jabol240 raised the priority of this task from to Incoming Queue.
jabol240 added a project: Restricted Project.
jabol240 added a subscriber: jabol240.

Just an update -- it's the same thing with a fresh config of chromium, no extensions, no nothing.

abyomi0 triaged this task as Trivial priority.Oct 25 2014, 9:26 AM
abyomi0 added a subscriber: abyomi0.

Does this happen in another desktop environment?
What Chromium version?
I had Chromium freeze when displaying empty tooltips, and it was a chromium bug.

chromium 38.0.2125.104. I sync with repo every day
I've only got E16 to compare, is it even relevant? It's working perfectly fine with E16 so far.

Ok I commented on that bug too, and will stick to it for a while and wait what happens. Thanks for your help :)

abyomi0 changed the visibility from "All Users" to "Public (No Login Required)".Nov 12 2014, 6:24 AM

Hi, how do you get those yellow tooltips ?

@bu5hm4n, hover over an open tab...like this. According to the crbug, it should be fixed soon...I think.

Oh okay, mhmm I cannot reproduce this :/

abyomi0 added a comment.EditedNov 21 2014, 1:16 PM

@bu5hm4n from what I can tell, I don't think this is Enlightenment's fault.

@jabol240, is the tooltip empty? (like in the first screenshot in the crbug.)

Wuhuu in this case, everything is cool! :)

raster added a subscriber: raster.Dec 17 2014, 12:23 AM

i have seen this - many times. i've poked at chromium and it seems hung waiting for something - what, i'm not sure. but the wm continues working without problems. restarting wm changes nothing - hang stays. i am unsure what could/would cause this on the chrome side, but chrome itself simply stops reacting to all events as if its hung in a mutex maybe ... or something similar, which smells of an internal chrome issue - at least at the gance i've seen.

it's same with new Opera.

If i remember correctly opera ist just a New ui for the chromium engine, so i guess this bug is part oft this engine.

mikeserv added a subscriber: mikeserv.EditedJan 16 2015, 4:21 PM

@raster @abyomi0 @bu5hm4n @jabol240

I have also seen this many times. My best guess is it has something to do with a scheduling race-condition involving chrome's separate name-spaces and separate rendering threads. Maybe even a job-control thing - like a setsid happens too soon. But the namespace sandbox is implemented in varying levels of severity depending on whether the thread is TCP/IP or HTML/CSS/Javascript parsing/execution or rendering - where the renderer thread sandbox is supposed to be most permissive, I think. Seems to me a collision in those conditions is bound to occur every once in a while.

In fact, after looking at the bug link, I'm inclined to believe it's related to another way it segregates display threads - chrome has the notion of separate *local* and *remote* tabs - like the way extensions are forbidden to affect the Play store and such. Probably there is a race there somewhere - and it definitely seems to have in-built gdk dependencies. One Ubuntu commenter pasted this in:

[7942:7942:0102/181230:ERROR:browser_main_loop.cc(209)] Gdk: gdk_window_set_user_time called on non-toplevel
[7942:7942:0102/181230:ERROR:browser_main_loop.cc(209)] Gdk: gdk_window_set_user_time called on non-toplevel
[7942:7942:0102/181231:ERROR:browser_main_loop.cc(209)] Gdk: gdk_window_set_user_time called on non-toplevel
[7942:7942:0102/181236:ERROR:browser_main_loop.cc(209)] Gdk: gdk_window_set_user_time called on non-toplevel
[7942:7942:0102/181236:ERROR:browser_main_loop.cc(209)] Gdk: gdk_window_set_user_time called on non-toplevel
[7942:7942:0102/181238:ERROR:browser_main_loop.cc(209)] Gdk: gdk_window_set_user_time called on non-toplevel
[7942:7942:0102/181238:ERROR:browser_main_loop.cc(209)] Gdk: gdk_window_set_user_time called on non-toplevel
[7942:7942:0102/181238:ERROR:browser_main_loop.cc(209)] Gdk: gdk_window_set_user_time called on non-toplevel
[7942:7942:0102/181247:ERROR:browser_main_loop.cc(209)] Gdk: gdk_window_set_user_time called on non-toplevel
[7942:7942:0102/181248:ERROR:browser_main_loop.cc(209)] Gdk: gdk_window_set_user_time called on non-toplevel
[7942:7942:0102/181250:ERROR:browser_main_loop.cc(209)] Gdk: gdk_window_set_user_time called on non-toplevel
[7942:7942:0102/181251:ERROR:browser_main_loop.cc(209)] Gdk: gdk_window_set_user_time called on non-toplevel

All of the GNOME commenters there seem to agree that their problems were solved by an update to 3.14+ and so there is some relationship to the desktop manager. A lot of the stuff also points to the *use system titlebar and borders* option. How would a gdk-bound app do that in E1[789]? Is there something we can adjust to handle that?

i don't know even what chrome is trying to do? chrome's communication between its processes, threads and its windows is its business. wm is not involved or part of that. wm handles requests like "move/resize/raise/lower this window" or "please activate this window" "the title changes" and also listening to damage evenmts that indicate something was drawn to a window and drawing thew changes. the wm deals with toplevel windows. ie ones that are not override-redirect that generally get a titlebar etc. from the wm.

yes - the chrome issue smells like a race condition internally somewhere. it may be that e (and older gnomes) simply trigger it by the order/timing of handling things like the request to show the tooltip window (if chromium implemented it as a normal window as opposed to override-redirect). but the issue is inside chromium somewhere if it can deadlock itself based on external events.

mikeserv added a comment.EditedJan 17 2015, 9:23 AM

@raster

Yeah - i was fishing. caNt blame me for trying. The override redirect jazz is about chrome carrying its own wm - aura. Its the de they use on the chromebooks. Linux has had it since v36 and Windows since v29/30 or something. With all of the right flags and a couple weeks a long, boring weekend devoted to the compiler you can get their whole de. I prefer e, though. Especially terminology - thanks for that, by the way.

In T1759#23, @mikeserv wrote:

@raster @abyomi0 @bu5hm4n @jabol240

I have also seen this many times. My best guess is it has something to do with a scheduling race-condition involving chrome's separate name-spaces and separate rendering threads. Maybe even a job-control thing - like a setsid happens too soon. But the namespace sandbox is implemented in varying levels of severity depending on whether the thread is TCP/IP or HTML/CSS/Javascript parsing/execution or rendering - where the renderer thread sandbox is supposed to be most permissive, I think. Seems to me a collision in those conditions is bound to occur every once in a while.

In fact, after looking at the bug link, I'm inclined to believe it's related to another way it segregates display threads - chrome has the notion of separate *local* and *remote* tabs - like the way extensions are forbidden to affect the Play store and such. Probably there is a race there somewhere - and it definitely seems to have in-built gdk dependencies. One Ubuntu commenter pasted this in:

[7942:7942:0102/181230:ERROR:browser_main_loop.cc(209)] Gdk: gdk_window_set_user_time called on non-toplevel
[7942:7942:0102/181230:ERROR:browser_main_loop.cc(209)] Gdk: gdk_window_set_user_time called on non-toplevel
[7942:7942:0102/181231:ERROR:browser_main_loop.cc(209)] Gdk: gdk_window_set_user_time called on non-toplevel
[7942:7942:0102/181236:ERROR:browser_main_loop.cc(209)] Gdk: gdk_window_set_user_time called on non-toplevel
[7942:7942:0102/181236:ERROR:browser_main_loop.cc(209)] Gdk: gdk_window_set_user_time called on non-toplevel
[7942:7942:0102/181238:ERROR:browser_main_loop.cc(209)] Gdk: gdk_window_set_user_time called on non-toplevel
[7942:7942:0102/181238:ERROR:browser_main_loop.cc(209)] Gdk: gdk_window_set_user_time called on non-toplevel
[7942:7942:0102/181238:ERROR:browser_main_loop.cc(209)] Gdk: gdk_window_set_user_time called on non-toplevel
[7942:7942:0102/181247:ERROR:browser_main_loop.cc(209)] Gdk: gdk_window_set_user_time called on non-toplevel
[7942:7942:0102/181248:ERROR:browser_main_loop.cc(209)] Gdk: gdk_window_set_user_time called on non-toplevel
[7942:7942:0102/181250:ERROR:browser_main_loop.cc(209)] Gdk: gdk_window_set_user_time called on non-toplevel
[7942:7942:0102/181251:ERROR:browser_main_loop.cc(209)] Gdk: gdk_window_set_user_time called on non-toplevel

All of the GNOME commenters there seem to agree that their problems were solved by an update to 3.14+ and so there is some relationship to the desktop manager. A lot of the stuff also points to the *use system titlebar and borders* option. How would a gdk-bound app do that in E1[789]? Is there something we can adjust to handle that?

I take it you're already aware of the issues with using Chromium in E with Use System Titlebar and borders? T2006
I would have like to tested it and see if it worked, but using Chromium like that under E becomes kind of difficult.

mikeserv added a comment.EditedJan 22 2015, 8:21 AM

@abyomi0 - I don't know if I've ever encountered the issue described in your link. I don't do a whole lot of clicking, though. Alt+esc or ctrl+alt+w is generally how I wind up adjusting window sizes/desktops. And my browser is usually maximized+borderless on a desktop of its own.

abyomi0 added a comment.EditedJan 22 2015, 10:28 AM

Hmm. It seem I can sort of get stuff done so long as I avoid using any of the window controls when I use Use System Tilebar and borders, but it somehow also ends up leading to a bunch of in E segfaults. (Something is really wrong...)

Just wanted to chime in I am seeing this issue on Chrome 40 with E19.3 and EFL 1.12 on Bodhi.

~Jeff

I fixed my previous issues with E crashing wildly...something to do with having E compiled with support for both X11 and Wayland.

I've been using Chromium since this past Friday and so far, Chromium hasn't frozen up like it usually did.
...
Oh...
Chromium will freeze up if I have Use System Titlebar and Borders unset, but it hasn't frozen up on me if I have Use System Titlebar and Borders set...well, not yet anyway.

Give it time. Still getting these lock ups here in Chrome.

raster closed this task as Invalid.Feb 9 2015, 6:43 PM
raster claimed this task.

it happens much less when using "system titlebar" - but again - this is a crhomium internal lockup. the tooltip windows are override-redirect windows and the wm doesn't manage them - chromium shouldnt be waiting on any messages from e etc. with them. yes - the compositor composites them but this is invisible to chromium - there is no back and forth communication here.

please file bugs with the crhomium dev team. there is nothing for us to do outside of chromium as e is not invovled here. (it may be some code path inside of chromium supporting or not some features in their new aurora back-end).

Oh great ! thx zmike !