Not working with firefox

Thanks for the report, I have this problem as well. It cannot be because of appmenu-qt though: appmenu-qt is used to expose menus for Qt applications on DBus. Firefox is not a Qt application so it does not use appmenu-qt. I suspect a bug in the DBusMenuImporter class of libdbusmenu-qt.

I'm trying to understand this bug...

First, monitoring dbus for menu do not give same information on Ubuntu and Kubuntu...

In fact, on Ubuntu, when unity-panel-service is killed, i get the same result as Kubuntu.

Here what i have on Ubuntu bus and can't get on Kubuntu when launching firefox:

method call sender=:1.154 -> dest=:1.168 serial=235 path=/com/canonical/menu/2E000E9; interface=com.canonical.dbusmenu; member=AboutToShow
method call sender=:1.154 -> dest=:1.168 serial=236 path=/com/canonical/menu/2E000E9; interface=com.canonical.dbusmenu; member=AboutToShow
method call sender=:1.154 -> dest=:1.168 serial=237 path=/com/canonical/menu/2E000E9; interface=com.canonical.dbusmenu; member=AboutToShow
method call sender=:1.154 -> dest=:1.168 serial=238 path=/com/canonical/menu/2E000E9; interface=com.canonical.dbusmenu; member=AboutToShow
method call sender=:1.154 -> dest=:1.168 serial=239 path=/com/canonical/menu/2E000E9; interface=com.canonical.dbusmenu; member=AboutToShow
method call sender=:1.154 -> dest=:1.168 serial=240 path=/com/canonical/menu/2E000E9; interface=com.canonical.dbusmenu; member=AboutToShow
method call sender=:1.154 -> dest=:1.168 serial=241 path=/com/canonical/menu/2E000E9; interface=com.canonical.dbusmenu; member=AboutToShow

It seems to be 7 firefox submenus.

Is this information useful ?

Le 23/11/2011 10:38, Bellegarde Cedric a écrit :
> I'm trying to understand this bug...
>
> First, monitoring dbus for menu do not give same information on Ubuntu
> and Kubuntu...
>
> In fact, on Ubuntu, when unity-panel-service is killed, i get the same
> result as Kubuntu.
>
> Here what i have on Ubuntu bus and can't get on Kubuntu when launching
> firefox:
>
> method call sender=:1.154 -> dest=:1.168 serial=235 path=/com/canonical/menu/2E000E9; interface=com.canonical.dbusmenu; member=AboutToShow
> method call sender=:1.154 -> dest=:1.168 serial=236 path=/com/canonical/menu/2E000E9; interface=com.canonical.dbusmenu; member=AboutToShow
> method call sender=:1.154 -> dest=:1.168 serial=237 path=/com/canonical/menu/2E000E9; interface=com.canonical.dbusmenu; member=AboutToShow
> method call sender=:1.154 -> dest=:1.168 serial=238 path=/com/canonical/menu/2E000E9; interface=com.canonical.dbusmenu; member=AboutToShow
> method call sender=:1.154 -> dest=:1.168 serial=239 path=/com/canonical/menu/2E000E9; interface=com.canonical.dbusmenu; member=AboutToShow
> method call sender=:1.154 -> dest=:1.168 serial=240 path=/com/canonical/menu/2E000E9; interface=com.canonical.dbusmenu; member=AboutToShow
> method call sender=:1.154 -> dest=:1.168 serial=241 path=/com/canonical/menu/2E000E9; interface=com.canonical.dbusmenu; member=AboutToShow
>
> It seems to be 7 firefox submenus.

That is strange. Did you get those 7 calls with only one click?

> Is this information useful ?

More information is always good. I have been willing to look into this
bug for a while but haven't found the time yet, so thank you for getting
into it.

I was imagining the bug to be caused by Firefox not answering fast
enough to dbusmenu-qt AboutToShow signal. Maybe you can try increasing
the timeout in the DBusMenuImporter class?

Hi.
Launching firefox on konsole I get this error

(firefox-bin:27345): LIBDBUSMENU-GTK-CRITICAL **: dbusmenu_menuitem_property_set_shortcut: assertion `gtk_accelerator_valid(key, modifier)' failed

about this bug.

I'm using KDE 4.7.2, Kubuntu 11.10.

I finally found some time to look at that bug. Thanks to Cédric info, I was able to work-around it by faking calls to AboutToShow. This is quite ugly but it works for me. Would be great if someone else could test the code from lp:~agateau/libdbusmenu-qt/workaround-xul-bug

Attached is a simple python-dbus script to illustrate the bug. It gets the top level menu items, call AboutToShow on the first item, wait 1 second and gets the children of the first item.

To properly reproduce the bug, one must run in an environment where unity-panel-service is not running but there is an appmenu registrar, otherwise unity-panel-service will call AboutToShow() behind our back.

An easy way to set up such an environment is to:
1. Install plasma-menubar-widget and kde-workspace-bin
2. Start a session in an environment which does not use unity-panel-service (kde, openbox,...)
3. Run "plasmoidviewer menubar" to get an appmenu registrar

One can then do the following:
1. Start firefox
2. Start d-feet
3. Find the address and objectpath firefox is using to expose its menu (it exposes 4 addresses, but only one of them has an objectpath named "/com/canonical/menu/<n>")
4. Call fake-menubar-widget with the address and objectpath => no content for File
5. Call fake-menubar-widget with the address and objectpath another time => one should get the content of the File menu

Here is the output of the script on my machine:

--------------- 1st call ----------------------------
$ ./fake-menubar-widget ':1.654' /com/canonical/menu/6C000EE
# menubar items
2: _Fichier
3: Éditio_n
4: _Affichage
5: _Historique
6: _Marque-pages
7: _Outils
8:

# Calling AboutToShow

# children of '_Fichier'

--------------- 2nd call ----------------------------
$ ./fake-menubar-widget ':1.654' /com/canonical/menu/6C000EE
# menubar items
2: _Fichier
3: Éditio_n
4: _Affichage
5: _Historique
6: _Marque-pages
7: _Outils
8:

# Calling AboutToShow

# children of '_Fichier'
9: Nouvel ongle_t
10: No_uvelle fenêtre
23: Ouvrir une _adresse…
11: _Ouvrir un fichier…
22: _Fermer l'onglet
24: Fe_rmer la fenêtre
12: <no label>
13: _Enregistrer sous…
14: E_nvoyer un lien vers la page…
15: <no label>
16: _Mise en page…
17: Aperçu a_vant impression
18: Im_primer…
19: <no label>
20: Travailler hors conne_xion
21: _Quitter

This isn't a bug in globalmenu-extension. Firefox builds its menus dynamically, and AboutToShow() exists in the protocol to tell the application that its menu is opening. It's a bug not to send this signal when a menu is opening

@Aurélien Gâteau
I installed libdbusmenu-qt from lp:~agateau/libdbusmenu-qt/workaround-xul-bug how you suggested.
Now both firefox then thunderbird work very well, although the menu isn't perfect (sometimes there are two menu at the same time, but this behavior is very very rare).
On the contrary the patch doesn't work with seamonkey (but globalmenu for seamonkey isn't official, so it can be a seamonkey extension bug).

Where did you get a seamonkey extension from?

I'm using the same extension of firefox, only with

<em:targetApplication>
   <!-- SeaMonkey -->
                <Description>
                        <em:id> ***Seamonkey ID *** </em:id>
                        <em:minVersion>2.0</em:minVersion>
                        <em:maxVersion>2.5.*</em:maxVersion>
                </Description>
</em:targetApplication>

in the rdf file.

http://www.imagehost.it/di-HXH3.png

@Aurélien Gâteau
Sometimes the button remains pressed (I note it if I try to close the menu pressing off out of the menubar, e.g. on the desktop).

http://www.imagehost.it/di-J0U8.png

However is much better then without your workaround.

> Firefox builds its menus dynamically, and AboutToShow() exists in the protocol to tell the application that its menu is opening. It's a bug not to send this signal when a menu is opening

My explanation was a bit confusing. The bug is that right now if you call AboutToShow() and immediatly after that call GetLayout() you get no content. If you call GetLayout() later then you get the content (cf my fake-menubar-widget script)

This behavior does not cause a problem with Unity because unity-panel-service calls AboutToShow() on all items at startup (cf Cédric dbus logs).

> Sometimes the button remains pressed (I note it if I try to close the menu pressing off out of the menubar, e.g. on the desktop).

Indeed, I have this problem as well.

Are you calling GetLayout() before getting the LayoutUpdated signal?

This works fine in Unity because dbusmenu-glib on the panel side only calls GetLayout() only when it gets the LayoutUpdated signal, so it's always guaranteed to work. If you don't wait for this signal, then it probably isn't going to work.

We actually ignore the first AboutToShow() that unity-panel-service sends anyway because it calls this for all top-level menus without following it with "opened" and "closed" events, which is fairly broken. We only process menu updates when we know a menu is opening to prevent Firefox from spamming the session bus with its entire menu structure every time you navigate a web page and the history menu changes (which would also result in Firefox spending time updating its menu right at the point when it should be spending CPU cycles laying out the page that you just loaded). This means that calling AboutToShow() without following it with "opened" and "closed" events (like unity-panel-service is doing) leaves Firefox in a state where it wastes time updating menus when it doesn't need to.

Actually, that probably should work, as everything we do on AboutToShow is synchronous, and we don't reply until we've finished everything (at which point, the menus are built). If you're waiting for the reply, then calling GetLayout() should work. If it doesn't work, it might be a dbusmenu bug instead

I guess the simple answer is that this is probably caused by the fact that we ignore the first AboutToShow() on top-level menus, to work around a unity-panel-service bug as mentioned above

Hmmm, are you not generating "opened" and "closed" events in dbusmenu-qt?

(sorry for the delay, vacations...)

Indeed dbusmenu-qt does not generate "opened" and "closed" events. I am going to give a try at generating them. Do you think it should be enough to fix this issue? I'd rather not propagate the unity-panel-service bug to dbusmenu-qt.

I just gave a try to the "opened" and "closed" events: it does not fix the bug. Only faking the AboutToShow fix it but that's an ugly hack, what should be done IMO is to get rid of the useless AboutToShow calls from unity-panel-service so that you do not need to skip them anymore.

Issue has been fixed in kded-appmenu

http://quickgit.kde.org/index.php?p=kded-appmenu.git&a=blob&h=9526cce6119e7e87a22cc83da0d57e3c12930d02&hb=4e091af2dcb07c8e0d05a27f2c68a700fcf2b4f4&f=src%2Fmodule%2Fappmenu.cpp

in AppMenuModule::slotLayoutUpdated().

We listen to LayoutUpdated signal for root menus and call AboutToShow() on submenus.

Thank You.

It's also fixed with plasma-widget-menubar using kded-appmenu :)

https://code.launchpad.net/~megabigbug/plasma-widget-menubar/appmenu-kde

> It's also fixed with plasma-widget-menubar using kded-appmenu :)

Nice! I'd like to get plasma-widget-menubar to uses kded-appmenu, but it's too late for Precise (afaik kded-appmenu has not been packaged yet, am I wrong?)

Anyway, I copied your code and it works fine, thanks! I simplified the code a bit, you may want to look at http://bazaar.launchpad.net/~agateau/plasma-widget-menubar/trunk/revision/103.1.2

that sounds great!

could you please package plasma-widget-menubar in your personal ppa so people that is interested in having these improvements can still get them?

I tried fix from comment #23 but didn't work for me, I guess because it interferes with kded-appmenu (https://launchpad.net/~gnumdk/+archive/ppa/). Using https://code.launchpad.net/~megabigbug/plasma-widget-menubar/appmenu-kde instead worked perfectly