GNOME Bugzilla – Bug 633028
Tracker bug for warnings, criticals and exceptions
Last modified: 2013-06-14 13:47:16 UTC
This is a tracker bug for everything that prevents for running with G_DEBUG=fatal_criticals, or causes JS exceptions (that are not fatal) or in anyway causes noise on stderr. This bug is to avoid having tenths of different bugs opened on minor issues.
Created attachment 173115 [details] [review] Avoid warnings on null actors for tray icons Plugging the GtkSocket icon can fail, in which case NaTrayManager emits tray-icon-removed but the icon has never emitted plug-added, thus the ShellTrayIcon has not been created. This results in various criticals and exceptions in the tray-icon-removed handler.
Created attachment 173116 [details] [review] Avoid warnings on leave-event for widgets tracking hover ClutterCrossingEvent->related can be NULL if the pointer is not under any actor. Unconditionally set hover to FALSE in that case.
Created attachment 173117 [details] [review] Allow for empty WM_CLASS and _NET_WM_NAME in tray icons The system tray specification says the hint should be set, but some icons leave it empty anyway. Don't throw exceptions in that case.
Created attachment 173120 [details] [review] Avoid warnings on null actors for tray icons Plugging the GtkSocket icon can fail, in which case NaTrayManager emits tray-icon-removed but the icon has never emitted plug-added, thus the ShellTrayIcon has not been created. This results in various criticals and exceptions in the tray-icon-removed handler.
Comment on attachment 173117 [details] [review] Allow for empty WM_CLASS and _NET_WM_NAME in tray icons >+ source = this._newSource(icon.title || '', icon.pid); The UI doesn't work well for sources with no titles. Maybe if there's no title try .wm_class, and if that's unset too, use _("Unknown"), which will look stupid and inspire people to file bugs against the bad icon?
Created attachment 173179 [details] [review] Allow for empty WM_CLASS and _NET_WM_NAME in tray icons The system tray specification says the hint should be set, but some icons leave it empty anyway. Don't throw exceptions in that case.
All patches have been committed, but I'm leaving the bug open in case we found out some other warning to fix.
Created attachment 173432 [details] [review] Don't remove the tray icons we don't add Tray icons replaced by a shell version are automatically filtered and never make to the tray container, but when removed by the client we were still trying to remove them from the tray, causing a warning.
Created attachment 173433 [details] [review] Do not remove destroyed actors from their container The container already connects to destroy and will do that for us, preventing a warning.
Comment on attachment 173432 [details] [review] Don't remove the tray icons we don't add ok. i think you could also just check "if (icon.get_parent() != null)"
Comment on attachment 173433 [details] [review] Do not remove destroyed actors from their container I made removeActor public because a menuitem subclass might need to remove an actor (that hasn't been destroyed yet). various possibilities... maybe add an alreadyDestroyed flag, which the destroy signal handler would pass true for?
(In reply to comment #11) > (From update of attachment 173433 [details] [review]) > I made removeActor public because a menuitem subclass might need to remove an > actor (that hasn't been destroyed yet). Why would you remove an actor without destroying it? It is easier to destroy then recreate when needed again. (Or to hide and show, if that change is happening often - of course that should be taken account of in _allocate)
(In reply to comment #12) > Why would you remove an actor without destroying it? > It is easier to destroy then recreate when needed again. well, that depends. anyway, you can just make removeActor private (_removeActor) if you'd rather
Created attachment 173482 [details] [review] Don't remove the tray icons we don't add Tray icons replaced by a shell version are automatically filtered and never make to the tray container, but when removed by the client we were still trying to remove them from the tray, causing a warning.
Created attachment 173483 [details] [review] Do not remove destroyed actors from their container The container already connects to destroy and will do that for us, preventing a warning.
Created attachment 173485 [details] [review] Do not remove destroyed actors from their container The container already connects to destroy and will do that for us, preventing a warning.
Created attachment 178083 [details] [review] LookingGlass: fix a Clutter warning After destroying an actor, it is no more parented anywhere, so we cannot allocate it.
Review of attachment 178083 [details] [review]: This makes sense. (Having an actor called "eventHandler" is kind of odd though, but unrelated to this patch)
Comment on attachment 178083 [details] [review] LookingGlass: fix a Clutter warning Attachment 178083 [details] pushed as 856207c - LookingGlass: fix a Clutter warning
Seeing assorted messages of the form: (mutter:12509): Clutter-WARNING **: The actor 'ShellGenericContainer' (or 'message-tray', or 'ClutterGroup') is currently inside an allocation cycle; calling clutter_actor_queue_relayout() is not recommended
These seem triggered by clicking on various things in the message tray.
Some more critical hunting, for random errors I found recently.
Created attachment 204872 [details] [review] App menu: only create the popup menu with a GMenu Since the application proxy is created asynchronously, at the time the GActionGroup (GActionMuxer) is created, there is no GDBusMenu yet. Defer creating the menu in that case. Also, clear out signal handlers if have no target application.
Created attachment 204873 [details] [review] Place display: don't use a StIcon for DND DND code assumes it can query the size of the actor before parenting, while StWidget asserts that get_preferred_size() is only called after the actor is on stage. This fixes a crash while dragging "Connect to..."
Created attachment 204874 [details] [review] ShellApp: don't use the app proxy before it's created The application proxy is created asynchrously after the dbus name is registed. This means that when tracking the first window (and therefore creating the first window GActionGroup) there is no app proxy yet.
Created attachment 204875 [details] [review] ShellApp: don't use the app proxy before it's created The application proxy is created asynchrously after the dbus name is registed. This means that when tracking the first window (and therefore creating the first window GActionGroup) there is no app proxy yet.
Comment on attachment 204875 [details] [review] ShellApp: don't use the app proxy before it's created the last patch was a dupe
Created attachment 205214 [details] [review] ShellEmbeddedWindow: don't update the size of a destroyed actor. shell_embedded_window_hide() can be called during widget destruction, after the associated ClutterActor has been already cleared out. Fix a crash in that case. ----- Yep, sorry, I made a mistake in attaching and then didn't check.
Review of attachment 205214 [details] [review]: Looks good.
Review of attachment 204873 [details] [review]: Looks good.
Review of attachment 204874 [details] [review]: Didn't test it but makes sense.
Attachment 204873 [details] pushed as 7da3903 - Place display: don't use a StIcon for DND Attachment 204874 [details] pushed as f4d13b9 - ShellApp: don't use the app proxy before it's created Attachment 205214 [details] pushed as abcca3d - ShellEmbeddedWindow: don't update the size of a destroyed actor.
Review of attachment 204872 [details] [review]: Sorry missed this one, looks fine as too.
Comment on attachment 204872 [details] [review] App menu: only create the popup menu with a GMenu Attachment 204872 [details] pushed as 1bac40f - App menu: only create the popup menu with a GMenu
It's faster to file new bugs than searching for a particular "bugs" bug, so let's just close this ...