After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 741033 - The places menu extension for gnome-shell fails to load when XDG user directories are not setup
The places menu extension for gnome-shell fails to load when XDG user directo...
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: extensions
3.14.x
Other FreeBSD
: Normal major
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
: 704211 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2014-12-02 16:35 UTC by Maxime Henrion
Modified: 2016-04-26 22:26 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Proposed fix (513 bytes, patch)
2014-12-02 17:25 UTC, Maxime Henrion
none Details | Review
Proposed fix in git format (1.06 KB, patch)
2014-12-02 17:56 UTC, Maxime Henrion
committed Details | Review

Description Maxime Henrion 2014-12-02 16:35:29 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.
Comment 1 Florian Müllner 2014-12-02 16:43:01 UTC
(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 ...
Comment 2 Maxime Henrion 2014-12-02 17:25:13 UTC
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.
Comment 3 Maxime Henrion 2014-12-02 17:30:11 UTC
(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!
Comment 4 Florian Müllner 2014-12-02 17:35:46 UTC
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)
Comment 5 Maxime Henrion 2014-12-02 17:56:37 UTC
Created attachment 292012 [details] [review]
Proposed fix in git format

Sure thing, here you go.
Comment 6 Florian Müllner 2014-12-02 17:59:06 UTC
Review of attachment 292012 [details] [review]:

Thanks!
Comment 7 Florian Müllner 2016-04-26 22:26:39 UTC
*** Bug 704211 has been marked as a duplicate of this bug. ***