xpra icon
Bug tracker and wiki

Opened 3 months ago

Closed 3 months ago

#2340 closed defect (upstream)

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

Reported by: tc424 Owned by: tc424
Priority: major Milestone: 3.0
Component: client Version: trunk
Keywords: Cc:

Description (last modified by Antoine Martin)

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

Attachments (4)

xs.log (181.6 KB) - added by tc424 3 months ago.
server log file
xi.txt (188.1 KB) - added by tc424 3 months ago.
xpra info output
xs2.log (70.5 KB) - added by tc424 3 months ago.
xpra server log with -d exec
menu.png (28.2 KB) - added by tc424 3 months ago.
menu as seen by XFCE

Download all attachments as: .zip

Change History (24)

comment:1 Changed 3 months ago by Antoine Martin

Description: modified (diff)
Owner: changed from Antoine Martin to tc424

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

comment:2 Changed 3 months ago by 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..

Changed 3 months ago by tc424

Attachment: xs.log added

server log file

comment:3 Changed 3 months ago by 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..

Changed 3 months ago by tc424

Attachment: xi.txt added

xpra info output

comment:4 Changed 3 months ago by 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.

comment:5 Changed 3 months ago by 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...

Changed 3 months ago by tc424

Attachment: xs2.log added

xpra server log with -d exec

comment:6 Changed 3 months ago by tc424

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

comment:7 Changed 3 months ago by tc424

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

comment:8 Changed 3 months ago by tc424

It seems to be something in the environment.

comment:9 Changed 3 months ago by tc424

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

comment:10 Changed 3 months ago by tc424

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

comment:11 Changed 3 months ago by 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.

comment:12 Changed 3 months ago by 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..

comment:13 Changed 3 months ago by 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...

comment:14 Changed 3 months ago by 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.

comment:15 Changed 3 months ago by 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..

Changed 3 months ago by tc424

Attachment: menu.png added

menu as seen by XFCE

comment:16 Changed 3 months ago by 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..

comment:17 Changed 3 months ago by 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>]

comment:18 Changed 3 months ago by 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.

comment:19 Changed 3 months ago by 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...)

comment:20 Changed 3 months ago by Antoine Martin

Resolution: upstream
Status: newclosed

Great investigation.

Closing as 'upstream' issue.

Note: See TracTickets for help on using tickets.