GNOME Bugzilla – Bug 741033
The places menu extension for gnome-shell fails to load when XDG user directories are not setup
Last modified: 2016-04-26 22:26:39 UTC
After updating my FreeBSD box to GNOME 3.14, I wasn't able to load the places menu gnome-shell extension. Using Looking Glass to get at the error message, I saw I was getting "Error: Argument 'path' (type utf8) may not be null". After sprinkling global.log() calls all over this extension's source code (it would have made my life a lot easier if gnome-shell was showing an actual stack trace along with line numbers...), I was finally able to locate the issue. The Glib.get_user_special_dir() function may legitimately return null when the XDG user directories are not setup, and the code simply doesn't handle that case. After configuring those directories properly using the xdg-user-dirs-update tool, everything was fine. While such a situation isn't likely to happen for many people since most of them use Linux distributions that already come with these things configured (or so I assume), I believe this extension should properly handle such a case, just skipping over those special directories if they cannot be found. The patch is extremely trivial and involves changing the "if (specialPath == homePath)" condition on line 205 of placeDisplay.js to "if (specialPath == null || specialPath == homePath)", such that we not only skip special directories if they point to the home directory, but also if we get a null. For what it's worth, this line number I'm giving here is still correct for the source code in the git repository, at the time of this writing.
(In reply to comment #0) > [...] I believe this extension should properly handle such a case, just > skipping over those special directories if they cannot be found. Yes, I agree. > The patch is extremely trivial Would you mind attaching a patch - you already described the fix, only fair to have it attributed to you ...
Created attachment 292008 [details] [review] Proposed fix I was told you guys would appreciate a patch however trivial the change might be, so here it is.
(In reply to comment #1) > (In reply to comment #0) > > [...] I believe this extension should properly handle such a case, just > > skipping over those special directories if they cannot be found. > > Yes, I agree. > > > > The patch is extremely trivial > > Would you mind attaching a patch - you already described the fix, only fair to > have it attributed to you ... Done. Not that it matters much, but I wasn't talking about you in my last comment; I only saw your reply after adding the patch. Thanks for the quick reply!
Could you use git-format-patch to create the patch? That way we'd have a correctly attributed complete (i.e. including a commit message) patch. (If it's too much trouble, we could do it with some environment variables)
Created attachment 292012 [details] [review] Proposed fix in git format Sure thing, here you go.
Review of attachment 292012 [details] [review]: Thanks!
*** Bug 704211 has been marked as a duplicate of this bug. ***