Xpra: Ticket #2340: "Run command" fails: 'NoneType' object is not iterable

Server: 2.5.2-r22875-1 / Ubuntu 16.04.6 Client: 3.0-20190621-r23016-1 / Ubuntu 18.04.2

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/xpra/client/gtk_base/gtk_client_base.py", line 371, in show_start_new_command
  File "/usr/lib/python3/dist-packages/xpra/client/gtk_base/start_new_command.py", line 36, in getStartNewCommand
    _instance = StartNewCommand(run_callback, can_share, xdg_menu)
  File "/usr/lib/python3/dist-packages/xpra/client/gtk_base/start_new_command.py", line 44, in __init__
    self.xdg_menu = typedict(xdg_menu)
TypeError: 'NoneType' object is not iterable

This is the set-up which previously experienced #2310, so I'm guessing the work-around for that broke things..?

Sat, 22 Jun 2019 13:00:40 GMT - Antoine Martin: owner, description changed

r23017 (trivial) should fix the error, but I'm not sure why your client doesn't have any menu data, was this expected?

Sat, 22 Jun 2019 13:09:34 GMT - tc424:

Good question - I assumed the fixes for #2310 removed all the menu data, but reading properly here, that's not the intention. If I hover over "start" I get "This server does not provide start menu data." When did the start menu stuff land? I'm running trunk clients against a 2.5.x server at the moment for no particular reason..

Sat, 22 Jun 2019 13:14:25 GMT - tc424: attachment set

server log file

Sat, 22 Jun 2019 13:15:05 GMT - tc424:

I see the start menu stuff is in 2.5.x, so that's not an excuse .. server log file attached but I can't see anything relevant..

Sat, 22 Jun 2019 13:19:42 GMT - tc424: attachment set

xpra info output

Sat, 22 Jun 2019 13:47:59 GMT - Antoine Martin:

Works fine here. Make sure that:

For the client, you can apply this patch to see logging when the menu data arrives:

--- xpra/client/ui_client_base.py	(revision 23016)
+++ xpra/client/ui_client_base.py	(working copy)
@@ -400,6 +400,7 @@
         self.server_start_new_commands = c.boolget("start-new-commands")
         if self.server_start_new_commands:
             self.server_xdg_menu = c.dictget("xdg-menu", None)
+        log.info("server: start-new-commands=%s, xdg-menu=%s", self.server_start_new_commands, self.server_xdg_menu)
         if self.start_new_commands or self.start_child_new_commands:
             if self.server_start_new_commands:
@@ -513,7 +514,7 @@
             log.info("unknown server setting changed: %s=%s", setting, repr_ellipsized(bytestostr(value)))
-        log("_process_setting_change: %s=%s", setting, value)
+        log.info("_process_setting_change: %s=%s", setting, value)
         #xdg-menu is too big to log
         if setting not in ("xdg-menu", ):
             log.info("server setting changed: %s=%s", setting, repr_ellipsized(str(value)))

2.5.x servers will trigger the first logging statement, 3.0 servers will trigger the second one.

It is theoretically possible for the xdg menu data to arrive after the "start new command" dialog is shown.

Sat, 22 Jun 2019 14:27:36 GMT - tc424:

steved@xubuntu:/run/user/1000/xpra$ grep-status -P python-xdg -s Version
Version: 0.25-4

Server log file doesn't seem to mention anything about the XDG data. This is really odd, as obviously it *was* working, otherwise I would never have discovered #2310...

Sat, 22 Jun 2019 14:28:05 GMT - tc424: attachment set

xpra server log with -d exec

Sat, 22 Jun 2019 15:19:53 GMT - tc424:

Hmm, it looks to be something user-specific - running the server on the same system as another user causes no problems..

Sat, 22 Jun 2019 15:26:03 GMT - tc424:

Just noticed xdg_helper.py can be invoked stand-alone - on the non-working system it produces no output..

Sat, 22 Jun 2019 15:39:29 GMT - tc424:

It seems to be something in the environment.

Sat, 22 Jun 2019 15:42:20 GMT - tc424:

It's XDG_CONFIG_DIRS - I get output if it's unset, not otherwise.

Sat, 22 Jun 2019 15:47:12 GMT - tc424:

Removing /etc/xdg/xdg-xubuntu from XDG_CONFIG_DIRS gives me output..

Sat, 22 Jun 2019 16:31:32 GMT - Antoine Martin:

As per XDG Base Directory Specification: There is a set of preference ordered base directories relative to which configuration files should be searched. This set of directories is defined by the environment variable $XDG_CONFIG_DIRS.

This is reminiscent of #2174.

Please try r23019 and see if that fixes things.

Sat, 22 Jun 2019 16:43:28 GMT - tc424:

Ugh, you're right - I'd just discovered unsetting XDG_MENU_PREFIX also makes it work. Giving up on bug chasing for the day, health has got the better of me..

Sun, 23 Jun 2019 11:41:21 GMT - tc424:

The problem is /etc/xdg/xdg-xubuntu/menus/xfce-applications.menu - xdg_helper.py finds nothing in it. /etc/xdg/menus/xfce-applications.menu works better, but I think xpra is not handling leaf nodes of the root menu that aren't submenus correctly...

Sun, 23 Jun 2019 12:57:02 GMT - Antoine Martin:

.. but I think xpra is not handling leaf nodes of the root menu that aren't submenus correctly...

Please post the output of xdg_helper.py -v. I'm not sure if it is xpra, python-xdg or the Ubuntu configuration, I am leaning towards the latter.

We have a number of workarounds for Ubuntu now, I would have expected a call to load the menus to just work. Having to tweak the environment to get the API call to return something is not how things should work.

Sun, 23 Jun 2019 14:24:45 GMT - tc424:

xdg_helper.py -v returns literally nothing. Much as I'm generally happy to blame [X]Ubuntu, I think it's xpra making assumptions about the menu structure that aren't true..

Sun, 23 Jun 2019 14:30:12 GMT - tc424: attachment set

menu as seen by XFCE

Sun, 23 Jun 2019 14:31:31 GMT - tc424:

Or maybe not. Adding some debug into xdg_helper.py, I get:

2019-06-23 15:26:06,551 non-menu submenu exo-web-browser.desktop
2019-06-23 15:26:06,551 non-menu submenu exo-mail-reader.desktop
2019-06-23 15:26:06,551 non-menu submenu <xdg.Menu.Separator instance at 0x7f526074acb0>
2019-06-23 15:26:06,552 non-menu submenu xfce-settings-manager.desktop
2019-06-23 15:26:06,552 non-menu submenu <xdg.Menu.Separator instance at 0x7f526074acf8>
2019-06-23 15:26:06,552 non-menu submenu <xdg.Menu.Separator instance at 0x7f526074ad40>
2019-06-23 15:26:06,552 non-menu submenu org.gnome.Software.desktop
2019-06-23 15:26:06,552 non-menu submenu <xdg.Menu.Separator instance at 0x7f526074ad88>
2019-06-23 15:26:06,552 non-menu submenu xfhelp4.desktop
2019-06-23 15:26:06,552 non-menu submenu xfce4-about.desktop
2019-06-23 15:26:06,552 non-menu submenu xfce4-session-logout.desktop

I have uploaded screengrab of what XFCE's normal start-menu type plugin sees - for some reason Xpra / pyxdg isn't seeing the submenus correctly..

Sun, 23 Jun 2019 15:25:14 GMT - Antoine Martin:

xpra processes the output of parse, so something similar to this:

python -c "from xdg.Menu import parse;print(list(parse().getEntries()))"

And expects to find a list of menu entries. ie on Fedora I get:

[<xdg.Menu.Menu instance at 0x7fed46d3abd8>, ... , <xdg.Menu.Menu instance at 0x7fed46ca9128>]

Sun, 23 Jun 2019 16:33:33 GMT - tc424:

Having gone around in circles and down multiple rabbit holes, I think it's pyxdg bug.

Both /etc/xdg/menus/xfce-applications.menu and /etc/xdg/xdg-xubuntu/menus/xfce-applications.menu use

        <Merge type="all"/>

Menu.py in pyxdg has:

        elif order[0] == "Merge":
            if order[1] == "files" or order[1] == "all":
                print "prepaing files sort"
                for menuentry in menu.MenuEntries:
                    if menuentry not in tmp_e:
                        print "adding " + str(menuentry)
            elif order[1] == "menus" or order[1] == "all":
                print "prepaing submenu sort"
                for submenu in menu.Submenus:
                    print "merging submenu " + str(submenu)
                    if submenu.Name not in tmp_s:
                        __parse_inline(submenu, menu)

(With my added random debug.) The logic here means that submenus are never actually processed for Merge types of "all" - doh. Will wander around and see if there any existing bug reports or fixes.

Sun, 23 Jun 2019 16:38:02 GMT - tc424:


(Gotta love it when projects move their bug trackers but don't update their project's web site links...)

Mon, 24 Jun 2019 01:46:23 GMT - Antoine Martin: status changed; resolution set

Great investigation.

Closing as 'upstream' issue.

Sat, 23 Jan 2021 05:48:41 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2340