The label is "Open" and not "Open with « The default app for this kind of stuff »" ?

Indeed, I have the same issue after updating to nautilus 2.19.4 (without updating anything else. It looks like it can no longer find the associated application.

The default action is working fine, it is the "Öffnen mit" aka "Open with" menu that doesn't work anymore.

It seems it was fixed by one of the 2.19.4 updates.

It has stopped working again :(

I can confirm this on a gentoo system.

Some additional information.
The problem can be worked around by actually clicking on the 'open with' menu entry. Not just waiting for the sub-menu to open.

This also applies to bug 458547 which I think is a dupe of this one.

*** Bug 448849 has been marked as a duplicate of this bug. ***

Ubuntu bug on https://bugs.launchpad.net/nautilus/+bug/121796, I've set the GNOME target because that would be nice to fix this one before 2.20

seb128, gnome-target is meant to be used on bugs severe enough to possibly
require delaying GNOME releases.  The target milestone is the field you want for bugs you'd like to remember to fix by a certain release.  You can add target
milestones for your product by clicking on the "Edit this product" link in the
lower-right hand corner of the browse.cgi ("product overview") page.  See also
the "Target Milestone" and "GNOME Target Milestone" sections of
http://bugzilla.gnome.org/page.cgi?id=bug-status.html.  :-)

Andre, thanks but I know what the gnome-target means and I used it because I think the bug should be fixed for 2.20, is there any other mean to list the bugs and suggest that they should be fixed for the new version?

https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/132372 describe it as a GTK issue

"In right-click menus, sub menus (eg the Create Document menu on the Desktop context menu) display fine, but when I primary(left) click on the entries, the menu disappears, but nothing happens. However, if I secondary(right) click on the entries, everything works: the menu disappears and the action occurs. Entries not in a sub menu (e.g. Change Desktop Background in the desktop context menu) work perfectly fine.

This happens in all GTK apps I've tried it in so far. Not sure about kde/qt apps as I don't have any kde apps installed. Interestingly though, the move to another workspace sub menu on the window list context menu is not affected.

I thought the problem was compiz fusion at first, but disabling it doesn't change anything. I also tried restarting X and logging in to gnome with compiz disabled, but the bug persists."

Bug #458588 would be a duplicate then ?

And maybe bug #464495 too

many people will run into this issue, so it definitely should be fixed for 2.20 release. seb128, you're totally right here, i'm sorry.

according to mitch (who would probably have prefered to not getting poked on this issue, hehe), all the right-click menus in gimp work with the new code.

can anybody provide a test case?

<mitch> so the problem is that when you use the right mouse button, submenus don't open any longer?

The submenu open, but when you click on a item in the submenu it does not always work (usually does not work).

I can also reproduce with gnome-terminal when asking to change profile, I had to do it 3 times before it changed, the one time was enough, then more than 10 times ...

(In reply to comment #11)
> However, if I secondary(right) click on the entries, everything works

Indeed, in gnome-terminal too, when right clicking on the menu entry it works fine 

*** Bug 458588 has been marked as a duplicate of this bug. ***

*** Bug 464495 has been marked as a duplicate of this bug. ***

I can reproduce this 95% of the time with metacity's "Move to Another Workspace" -> submenu when its built when right-clicking the title bar. The same submenu works flawlessly when left clicking on the window icon.

And I think I found the reliable way to reproduce the same thing. 
The workspaces submenu doesn't work when the rightclick on the metacity title bar is held down a little bit longer. It works fine if the click is released asap.

*** Bug 474331 has been marked as a duplicate of this bug. ***

Created attachment 95149 [details]
Shows a backtrace of how far the code makes it

This backtrace shows the code path of when a document _is_ created.  It also shows the spot at which the bug described here stops heading down the normal code path (at frames #14 and #15).

I tracked it down to gtk_menu_button_release (gtkmenushell.c:669) and noticed that there were a lot of changes made in r17659, which contained a bunch of changes surrounding submenus.

http://svn.gnome.org/viewcvs/gtk%2B?view=revision&revision=17659

I'm not expert in this area, but perhaps this information will help one of you figure out what's going on more quickly?

Mitch, do you have any insight here ?

Created attachment 95164 [details]
testcase

Here is a small testcase.
To reproduce, right-click on the window and hold for a bit after the menu pops up.
Then open a submenu and left-click on an item. Note that the callback is not triggered.

Ok, I tracked this further down.

With trunk, what I see that menu_shell->button remains set to 1 or 3 in the
slow-release case. The later click with the other button then triggers

      if (menu_shell->button && (event->button != menu_shell->button))

With 2.10, a slow release gets passed to the menu_shell_button_release function and causes menu_shell->button to be reset to 0, which later makes the condition false.

This change in behaviour is caused by the "don't pass down" part of 
http://svn.gnome.org/viewcvs/gtk%2B/trunk/gtk/gtkmenu.c?r1=17570&r2=17571

Created attachment 95371 [details] [review]
Ugly patch which fixes the issue

Fixed in SVN:

2007-09-11  Michael Natterer  <mitch@imendio.com>

	* gtk/gtkmenu.c (gtk_menu_button_release): Make sure
	menu_shell->button gets reset to 0 when we bail out early here
	instead of chaining up, so it is in a consistent state for the
	next press/release in GtkMenuShell. Fixes bug #449371.