"Run command" fails: 'NoneType' object is not iterable

[tc424]

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
    self.server_xdg_menu)
  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..?

[Antoine Martin]

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

[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..

[tc424]

server log file

[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..

[tc424]

xpra info output

[Antoine Martin]

Works fine here.
Make sure that:

• the server has python-xdg installed
• -d exec shows the xdg menu data being loaded

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:
                 self.after_handshake(self.send_start_new_commands)
@@ -513,7 +514,7 @@
         else:
             log.info("unknown server setting changed: %s=%s", setting, repr_ellipsized(bytestostr(value)))
             return
-        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.

[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...

[tc424]

xpra server log with -d exec

[tc424]

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

[tc424]

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

[tc424]

It seems to be something in the environment.

[tc424]

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

[tc424]

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

[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.

[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..

[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...

[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.

[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..

[tc424]

menu as seen by XFCE

[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..

[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>]

[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"
                menu.MenuEntries.sort()
                for menuentry in menu.MenuEntries:
                    if menuentry not in tmp_e:
                        menu.Entries.append(menuentry)
                        print "adding " + str(menuentry)
            elif order[1] == "menus" or order[1] == "all":
                menu.Submenus.sort()
                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.

[tc424]

​https://gitlab.freedesktop.org/xdg/pyxdg/issues/12

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

[Antoine Martin]

Great investigation.

Closing as 'upstream' issue.

[migration script]

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