Fallback menus shown for windows on the blacklist

Reported by Matthew Paul Thomas on 2010-09-08
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Application Menu Indicator
High
Ted Gould
Ayatana Design
Undecided
Unassigned
Ayatana Ubuntu
High
Ted Gould
BAMF
Undecided
Jason Smith
Unity
Undecided
Unassigned
libdbusmenu-qt
Undecided
Aurélien Gâteau
bamf (Ubuntu)
Undecided
Unassigned
fontforge (Ubuntu)
Undecided
Unassigned

Bug Description

If a window has no menus of its own and is not on the blacklist, the fallback "File" and "Edit" window menus should be shown in the panel.

If a window *is* on the blacklist (e.g. a Firefox window), no window menus should be shown in the panel at all. Currently they're showing the fallback menus too, resulting in duelling File and Edit menus.

Ted Gould (ted) on 2010-09-08
Changed in indicator-appmenu:
importance: Undecided → High
milestone: none → 0.0.10
status: New → Confirmed
David Barth (dbarth) on 2010-09-08
Changed in ayatana-ubuntu:
importance: Undecided → Medium
milestone: none → ubuntu-10.10
assignee: nobody → Ted Gould (ted)
importance: Medium → High
status: New → Confirmed
Ted Gould (ted) on 2010-09-09
Changed in indicator-appmenu:
milestone: 0.0.10 → 0.0.11
Hernando Torque (htorque) wrote :

FWIW, the same happens when running not blacklisted applications with sudo. Also, running just 'openoffice.org' will show the desktop menu instead of the fallback menu.

Omer Akram (om26er) wrote :

>the same happens when running not blacklisted applications with sudo.

bug 592842

Hernando Torque (htorque) wrote :

I'm already subscribed to that one. :-P

Just added this here, so we won't get a fix for blacklisted apps only.

Ted Gould (ted) on 2010-09-13
Changed in indicator-appmenu:
status: Confirmed → In Progress
assignee: nobody → Ted Gould (ted)
Ted Gould (ted) wrote :

Okay, so sudo is a different problem that this bug isn't about. I beleive there's already a wishlist bug on it. This is for applications that have menus, that aren't exported into the panel so there isn't a stub menu for them.

To that aim, there is two ways the proposed branch works. One is that it has a list of desktop files that are automatically removed. It's a short list of apps that are a PITA to upload or fix easily. Two, it will work with the desktop files of any app. If that app as the key in its desktop file "X-Ayatana-Appmenu-Show-Stubs=False" then the stubs will not be shown.

Changed in bamf:
status: New → Fix Committed
assignee: nobody → Jason Smith (jassmith)
Changed in ayatana-ubuntu:
status: Confirmed → In Progress
Ted Gould (ted) wrote :
Changed in fontforge (Ubuntu):
status: New → Confirmed
Hernando Torque (htorque) wrote :

The sudo bug 592842 mentioned by Omer Akram actually is about "sudo apps not working with appmenu" - ok, but if they aren't working right now, shouldn't they be handled like blacklisted applications? Right now they show the same behavior as blacklisted ones (= this bug).

Ted Gould (ted) wrote :

No, sudo apps are unlikely to work. And in general, they should go away. If someone found a way to patch them or something I'd probably accept the patch, but I think time would be better spent migrating them away from sudo to a proper PolicyKit backend-frontend separation. I'm personally for removing sudo from main.

tags: added: patch
Ted Gould (ted) on 2010-09-14
Changed in indicator-appmenu:
status: In Progress → Fix Committed
Ted Gould (ted) on 2010-09-15
Changed in indicator-appmenu:
status: Fix Committed → Fix Released

Why are sudo apps unsupportable? That's separate from whether sudo is a
good idea - it's here for a while, till the full migration /
architecture for separation is widely in use.

Mark

Ted Gould (ted) wrote :

Added in libdbusmenu-qt as I've been able to replicate this using Mumble and the preferences dialog. It's likely to be the same cause. The libdbusmenu-qt getting blocked doing the preferences action and not sending back the response. Then indicator-appmenu believes that the program has died and retries.

Changed in libdbusmenu-qt:
assignee: nobody → Aurélien Gâteau (agateau)
status: New → Confirmed
assignee: Aurélien Gâteau (agateau) → nobody
assignee: nobody → Aurélien Gâteau (agateau)
Ted Gould (ted) wrote :

@Mark, the difficulty with sudo applications is that they don't have access to the session bus of the user. I've looked at trying to give them the path (as a hack) but it still wasn't able to connect. With enough work, I'm sure it could be made to work together. But, considering how many GUI apps need to be run with sudo, I don't think it's worth the effort. The only one I know of is wireshark, and even that isn't required, just easier.

Omer Akram (om26er) wrote :

I think chromium-browser should also be blacklisted.

David Barth (dbarth) wrote :

Right, on the sudo apps, there is a separate bug tracking the issue: https://bugs.launchpad.net/indicator-appmenu/+bug/592842. sudo apps are bound to a distinct dbus session. By contrast, they access the same X display, but get permission for that because sudo is mediating the auth exchange. We haven't found a way to properly re-route dbusmenus published on another session bus to the bus that the panel indicator is listening on.

David Barth (dbarth) wrote :

The blacklist mechanism has been implemented and released.
The list of blacklisted apps needs to be reviewed: tracked on a separate bug task for ayatana-design.

Changed in ayatana-ubuntu:
status: In Progress → Fix Released
David Barth (dbarth) wrote :

Adding an ayatana-design task to review the list of applications to blacklist, ie for which the menu stubs should not be used.

Mark Shuttleworth (sabdfl) wrote :

OK, sudo isn't a blocker for me for Maverick. Thanks for the
clarifications. Bet we could solve the problem!

Mark

Matthew Paul Thomas (mpt) wrote :

The list of blacklisted applications should be Firefox, Thunderbird, any other XUL applications in Main or Universe, and OpenOffice.org. That is, all applications for which we plan to recognize their toolkit's menus in future but do not yet. Once we do recognize XUL and VCL menus, the blacklist can be retired.

The blacklist should not include Chromium or Chrome, because (a) they currently have no menu bar at all, (b) "File" > "Close" usefully works right now and the "Edit" items could too, and (c) we want them to start using a full set of menus (as they do on Mac OS X), and their developers shouldn't be roadblocked when they try.

For applications that use other toolkits, such as Blender and FontForge, it should be their responsibility to integrate the menus themselves, just as it was for Mozilla and OpenOffice.org developers on the Mac for example.

Martin Pitt (pitti) wrote :

This is slightly confusing. This bug is still (mostly) open, but it seems that current Maverick is already behaving that way. Just now Ken VanDine proposed yet another package to hide the menu, and it seems we have to play a lot of catch-up with a lot of little dialogs which don't have menus, but cause these weird "File/Edit" menus to appear. Up to a few days ago, even the empty desktop had those menus (not sure whether those got removed by now). Also, there's probably a lot of third-party apps which we don't even know about yet, so having a blacklist sounds like a battle which we can't win.

Could we perhaps switch to a whitelist to cover the two or three apps where this extra menu actually makes sense? Or disable it for Maverick, until we get a better approach?

Aurélien Gâteau (agateau) wrote :

blacklist is implemented by indicator-appmenu, not by libdbusmenu-$toolkit

Changed in libdbusmenu-qt:
status: Confirmed → Invalid
Didier Roche (didrocks) on 2011-02-21
Changed in unity:
status: New → Fix Committed
Changed in bamf (Ubuntu):
status: New → Fix Committed
Omer Akram (om26er) on 2011-02-22
Changed in bamf:
status: Fix Committed → Fix Released
Changed in bamf (Ubuntu):
status: Fix Committed → Fix Released
Changed in unity:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments