Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1353249 - gnome-shell-extension-apps-menu will crash when alternate AppDirs are defined in /etc/xdg/menus/applications-merged
Summary: gnome-shell-extension-apps-menu will crash when alternate AppDirs are defined...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: gnome-shell-extensions
Version: 7.2
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Florian Müllner
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-07-06 15:56 UTC by Jonathan Billings
Modified: 2016-11-04 01:44 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-04 01:44:53 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
GNOME Bugzilla 762206 None None None 2016-07-06 15:56:28 UTC
Red Hat Product Errata RHBA-2016:2258 normal SHIPPED_LIVE gnome-shell, gnome-shell-extensions, and gtk3 bug fix and enhancement update 2016-11-03 13:32:13 UTC

Description Jonathan Billings 2016-07-06 15:56:29 UTC
Description of problem:
We have several applications we provide from a network volume.  We defined an alternate AppDir and DirectoryDir in a file in /etc/xdg/menus/applications-merged/.  It looks something like this:

 cat /etc/xdg/menus/applications-merged/caen.menu 
<!DOCTYPE Menu PUBLIC "-//freedesktop//DTD Menu 1.0//EN"
 "http://www.freedesktop.org/standards/menu-spec/1.0/menu.dtd">

<Menu>

  <Name>Applications</Name>
  
  <!-- Add caen applications to menus -->
  <AppDir>/usr/caen/misc/menus/applications</AppDir>
  <DirectoryDir>/usr/caen/misc/menus/directories</DirectoryDir>

<Menu>
<Name>MCAD ECAD MCAE Tools</Name>
<Directory>MCAD.directory</Directory>
<Include>
<And>
<Category>MCAD</Category>
</And>
</Include>
</Menu>
<Menu>
<Name>Engineering Applications</Name>
<Directory>ENGIN.directory</Directory>
<Include>
<And>
<Category>ENGIN</Category>
</And>
</Include>
</Menu>
  
</Menu> <!-- End Applications -->


We define several directories and applications in /usr/caen/misc/menus.  If we run Cinnamon Desktop from EPEL, they show up fine, but if we run Gnome Classic, when you click on the menu, and hover over the "MCAD ECAD MCAE Tools" or the "Engineering Applications" menu, it doesn't highlight it nor does it open the submenu.

We discovered if we updated one of our .desktop files to use one of the Categories used by one of the built-in menus, that menu entry would also not highlight and show the submenu.

I looked at the logs, and discovered that when I hovered over a menu that had desktop definitions from our alternate AppDir, this error appeared in the user's session logs:


Jul 06 10:32:43 caen-z240 gnome-session[8652]: (gnome-shell:8910): Gjs-WARNING **: JS ERROR: TypeError: app is null
Jul 06 10:32:43 caen-z240 gnome-session[8652]: ApplicationMenuItem<._init@/usr/share/gnome-shell/extensions/apps-menu@gnome-shell-extensions.gcampax.github.com/extension.js:62
Jul 06 10:32:43 caen-z240 gnome-session[8652]: wrapper@resource:///org/gnome/gjs/modules/lang.js:169
Jul 06 10:32:43 caen-z240 gnome-session[8652]: _Base.prototype._construct@resource:///org/gnome/gjs/modules/lang.js:110
Jul 06 10:32:43 caen-z240 gnome-session[8652]: Class.prototype._construct/newClass@resource:///org/gnome/gjs/modules/lang.js:204
Jul 06 10:32:43 caen-z240 gnome-session[8652]: ApplicationsButton<._displayButtons@/usr/share/gnome-shell/extensions/apps-menu@gnome-shell-extensions.gcampax.github.com/extension.js:
Jul 06 10:32:43 caen-z240 gnome-session[8652]: wrapper@resource:///org/gnome/gjs/modules/lang.js:169
Jul 06 10:32:43 caen-z240 gnome-session[8652]: ApplicationsButton<.selectCategory@/usr/share/gnome-shell/extensions/apps-menu@gnome-shell-extensions.gcampax.github.com/extension.js:5
Jul 06 10:32:43 caen-z240 gnome-session[8652]: wrapper@resource:///org/gnome/gjs/modules/lang.js:169
Jul 06 10:32:43 caen-z240 gnome-session[8652]: CategoryMenuItem<.setActive@/usr/share/gnome-shell/extensions/apps-menu@gnome-shell-extensions.gcampax.github.com/extension.js:204
Jul 06 10:32:43 caen-z240 gnome-session[8652]: wrapper@resource:///org/gnome/gjs/modules/lang.js:169
Jul 06 10:32:43 caen-z240 gnome-session[8652]: PopupBaseMenuItem<._onHoverChanged@resource:///org/gnome/shell/ui/popupMenu.js:149
Jul 06 10:32:43 caen-z240 gnome-session[8652]: wrapper@resource:///org/gnome/gjs/modules/lang.js:169
Jul 06 10:32:43 caen-z240 gnome-session[8652]: CategoryMenuItem<._onMotionEvent@/usr/share/gnome-shell/extensions/apps-menu@gnome-shell-extensions.gcampax.github.com/extension.js:190
Jul 06 10:32:43 caen-z240 gnome-session[8652]: wrapper@resource:///org/gnome/gjs/modules/lang.js:169

Looking in /usr/share/gnome-shell/extensions/apps-menu@gnome-shell-extensions.gcampax.github.com/extension.js, I believe the failure is in the _loadCategory function, on line 424:

   424                  let app = appSys.lookup_app(entry.get_desktop_file_id());
   425                  if (appInfo.should_show()) {
   426                      let menu_id = dir.get_menu_id();
   427                      this.applicationsByCategory[categoryId].push(app);
   428                  }

What is happening is that appSys.lookup_app() is returning null, and JS just stops and logs the above error.  I made a minor modification to the extension.js file so it looks like this:

   424                  let app = appSys.lookup_app(entry.get_desktop_file_id());
   425                  if (app == null) {
   426                      global.log("null app: "+ entry.get_desktop_file_id())
   427                  } else if (appInfo.should_show()) {
   428                      let menu_id = dir.get_menu_id();
   429                      this.applicationsByCategory[categoryId].push(app);
   430                  }

and now when I log in, I get a bunch of log entries in the session log that look like this:

Jul 06 11:16:32 caen-z240 gnome-session[13068]: Gjs-Message: JS LOG: null app: ENGIN-ChemkinProv17.0.desktop
Jul 06 11:16:32 caen-z240 gnome-session[13068]: Gjs-Message: JS LOG: null app: MCAD-ABAQUS-CAE2016.desktop
Jul 06 11:16:32 caen-z240 gnome-session[13068]: Gjs-Message: JS LOG: null app: MCAD-ABAQUS-DOC2016.desktop

Now the Application menu doesn't generate any errors in the logs, but of course, my menus don't appear.  I was going to file a bug against the upstream Gnome project, but I ran across this bug in their BZ:  https://bugzilla.gnome.org/show_bug.cgi?id=762206

This makes me think that the Gnome3 developers don't intend to support alternate AppDirs.  Sadly, the existing XDG spec for menu definitions continues to have the definition, and other desktop environments are fine using them.  (See the latest spec to see it is still defined: https://specifications.freedesktop.org/menu-spec/menu-spec-latest.html)

In the end, I made a symlink /usr/local/share/applications to point at our alternative AppDir, since we weren't using /usr/local/share/applications already, but this is obviously a limited solution, it breaks the 'filesystem' package's RPM validation check:

# rpm -V filesystem
.....UG..    /usr/local/share/applications

So we have to manage that symlink externally to RPM now.

It would be great if this package could be updated with fixed code to at least better handle failures.  It would be great if we could get back the functionality to be able to use alternative AppDirs.


Version-Release number of selected component (if applicable):
gnome-shell-extension-apps-menu-3.14.4-13.el7.noarch

How reproducible:
Always

Steps to Reproduce:
1. Define an AppDir in a merged file from /etc/xdg/menus/applications-merged/
2. Define a desktop entry that has a Category that would show up in any of the defined menus
3. Try to select that menu from the Applications menu

Actual results:
Application Menu will show menu but not highlight it when you hover over it, and will not show any valid entries, even if they are from standard locations provided by packages.

Expected results:
Additional menu entries will appear and be selectable.

Additional info:

Comment 2 Florian Müllner 2016-07-06 18:33:26 UTC
(In reply to Jonathan Billings from comment #0)
> What is happening is that appSys.lookup_app() is returning null, and JS just
> stops and logs the above error.  I made a minor modification to the
> extension.js file so it looks like this:
> 
>    424                  let app =
> appSys.lookup_app(entry.get_desktop_file_id());
>    425                  if (app == null) {
>    426                      global.log("null app: "+
> entry.get_desktop_file_id())
>    427                  } else if (appInfo.should_show()) {
>    428                      let menu_id = dir.get_menu_id();
>    429                     
> this.applicationsByCategory[categoryId].push(app);
>    430                  }
> 
> [...]
> Now the Application menu doesn't generate any errors in the logs, but of
> course, my menus don't appear.  I was going to file a bug against the
> upstream Gnome project, but I ran across this bug in their BZ: 
> https://bugzilla.gnome.org/show_bug.cgi?id=762206
> 
> This makes me think that the Gnome3 developers don't intend to support
> alternate AppDirs.

Right. The reasoning is that no other component that deals with applications handles .desktop files in non-standard locations ("Open With" in the file manager, default applications in Settings, pinning apps as favorite to gnome-shell's dash, ...), and we don't want all those components do the complex processing of the menu definitions.

Those applications won't show up gnome-shell's "normal" application list (i.e. the one in the overview, not the application menu in gnome-classic). So the only fix we will consider upstream is to handle the case where the lookup failed and ignore the entry (as your modification, but without the logging).

I would be fine with supporting this case downstream though - it only requires a minor modification in gnome-shell and the extension. However ...


> In the end, I made a symlink /usr/local/share/applications to point at our
> alternative AppDir, since we weren't using /usr/local/share/applications
> already, but this is obviously a limited solution, it breaks the
> 'filesystem' package's RPM validation check:
> 
> # rpm -V filesystem
> .....UG..    /usr/local/share/applications
> 
> So we have to manage that symlink externally to RPM now.

... have you considered adding /usr/caen/misc/menus to XDG_DATA_DIRS? This should be possible by installing a snippet like

  export XDG_DATA_DIRS=${XDG_DATA_DIRS:-/usr:/usr/local}:/usr/caen/misc/menus

in /etc/profile.d/caen.sh or similar. With this change, the applications would not only show up in the application menu, but also work in all the cases mentioned above.

Comment 3 Jonathan Billings 2016-07-07 12:38:53 UTC
Using $XDG_DATA_DIRS is a good solution, although the appropriate definition would be:

export XDG_DATA_DIRS=${XDG_DATA_DIRS:-/usr/share:/usr/local/share}:/usr/caen/misc/menus

... and in my case, I put it in /etc/X11/xinit/xinitrc.d/99-caenapps.sh, since it really only makes sense to evaluate it during graphical login.

I believe that the issue of an undefined 'app' variable has been fixed in newer versions of the extension, and I'm sure it's a lot better handled than my crude fix.

Comment 4 Florian Müllner 2016-07-07 12:47:46 UTC
(In reply to Jonathan Billings from comment #3)
> Using $XDG_DATA_DIRS is a good solution, although the appropriate definition
> would be:
> 
> export
> XDG_DATA_DIRS=${XDG_DATA_DIRS:-/usr/share:/usr/local/share}:/usr/caen/misc/
> menus

Ah yes, sorry for the slip.


> I believe that the issue of an undefined 'app' variable has been fixed in
> newer versions of the extension

No, it's still present on master. As mentioned in the previous comment, I don't think we want anything besides

  if (!app)
     continue;

upstream, but I'm up to adding downstream patches to make those apps show up properly in the menu, if that's still wanted.

Comment 8 errata-xmlrpc 2016-11-04 01:44:53 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2258.html


Note You need to log in before you can comment on or make changes to this bug.