#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 )
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)
Change History (25)
comment:1 Changed 3 years ago by
Description: | modified (diff) |
---|---|
Owner: | changed from Antoine Martin to tc424 |
comment:2 Changed 3 years ago by
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..
comment:3 Changed 3 years ago by
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..
comment:4 Changed 3 years ago by
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 years ago by
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...
comment:6 Changed 3 years ago by
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 years ago by
Just noticed xdg_helper.py can be invoked stand-alone - on the non-working system it produces no output..
comment:10 Changed 3 years ago by
Removing /etc/xdg/xdg-xubuntu from XDG_CONFIG_DIRS gives me output..
comment:11 Changed 3 years ago by
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 years ago by
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 years ago by
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 years ago by
.. 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 years ago by
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..
comment:16 Changed 3 years ago by
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 years ago by
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 years ago by
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 years ago by
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 years ago by
Resolution: | → upstream |
---|---|
Status: | new → closed |
Great investigation.
Closing as 'upstream' issue.
comment:21 Changed 16 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2340
r23017 (trivial) should fix the error, but I'm not sure why your client doesn't have any menu data, was this expected?