GNOME Bugzilla – Bug 314431
gtk_window_activate_key messes up keybindings
Last modified: 2011-06-11 16:27:32 UTC
1. Open nautilus in browser mode 2. Press Control-L 3. Type a path (eg. /usr/local/) 4. Press Control-W Expected results: 5. The last part of the path is removed from the location entry bar Actual results: 5. The nautilus window closes.
Forgot to add: the dialog that pops up after pressing Control-L in spatial mode works as intended.
Usability team, what do you think? Should we have a preference which forces the Nautilus location entry to obey some common shell keybindings?
Could it follow the gtk key (what you change to Emacs). It is in gconf under /desktop/gnome/interface/gtk_key_theme.
It doesn't follow the key? I first supposed that this bug report would be about Emacs keybinding borkage, but according to some random site, Emacs has ctrl-w bound to "save buffer". Whatever, ":w" is preferable :x.
Well, the ctrl-W is just the binding for GtkEntry widgets. The GtkEntry should just behave like all other GtkEntries do (that is: respect ctrl-W or any other keybindig be it the default or the Emacs one). Nautilus just ignores that we are editing a GtkEntry.
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
Apologies for spam... marking as AP4 to reflect accessibility impact.
The issue is that the key-press-event handler of GtkWindow picks up the GtkActions keybindings before the widgets' handlers, using gtk_window_activate_key. I came up with the patch on the mailing list but our widgets eat too many key bindings, which is not good. Let's fix this up during the 2.15 cycle (i.e. now).
*** Bug 345528 has been marked as a duplicate of this bug. ***
Any progress on this one? Epiphany has some code that fixes this issue (it was taken from Galeon).
This is still not fixed as of Nautilus 2.16.1 (Ubuntu Edgy).
(/me cries silently)
Still there with 2.21.92, modifying fields.
Created attachment 106280 [details] [review] patch This is adapted from Epiphany, works just fine in my testing.
*** Bug 369636 has been marked as a duplicate of this bug. ***
Created attachment 106310 [details] [review] patch v2 Much better patch, fixes also (at least) the case when Shift+Delete is pressed while renaming (see bug #369636).
*** Bug 520475 has been marked as a duplicate of this bug. ***
This patch scares me a bit. Gtk+ runs mnemonics and accelerators before widgets by design, and this is how it works in all other applications. To just change this order may well affect many unexpected things like input methods etc. Doesn't this bug affect all Gtk+ apps that have an entry and use the standard ctrl-w keybinding for window close? Seems kinda weird to hack around it in each app. Maybe we should ask the Gtk+ people what the rationale was for doing accelerators before widgets and if this can be fixed in some standard way. For the patch itself, if we really want to change the order like that we should do the shortcutting before the extra_window_keybindings too. Also, the ephi code limits the shortcuts to a smaller set of key presses, thus limiting the risk of problems, while this patch seems to shortcut everything.
Reasons for the ordering: - Accelerators are visible and discoverable to users, most users don't know about every possible key binding that might be in their key theme. So, I considered it more important to have accelerators working. - That's how XEMBED works ... accelerators are processed before sending them to the embedded client, and never sent back. The fact that a text entry might be inside an embedded application shouldn't affect whether C-w works, so you'd have to modify XEMBED. I don't see how shifting around things on a per-app basis helps or makes sense. [ If I had to do it again, there wouldn't be key themes at all ... the only way things stay same is if: - key shortcuts for widgets - mnemonics - menu accelerators Stay separated. And that doesn't work when you start adding control-<letter> key shortcuts. ]
Hmm.. We don't user xembed, and text entries are very rarely focused in nautilus, and when they are they are generally short lived and the focus of the operation, so i don't think those reasons are really all that important to nautilus. And, when this problem strikes its really kinda bad, shift-delete can actually cause data loss. So, i think we want to fix this. The gedit-window.c approach looks sane to me.
Created attachment 108318 [details] [review] patch v3 Adapt code from GEdit to fix this bug. Works well for me both in the Ctrl+W case and in the Shift+Delete one.
Cosimo: Thanks for your work, please commit the patch to trunk and to the GNOME 2.22 branch.
Thanks for the review, committed. 2008-04-27 Cosimo Cecchi <cosimoc@gnome.org> * src/nautilus-window.c: (nautilus_window_key_press_event): Reverse the order in which the keybindings are processed by the NautilusWindow, and use the same approach as GEdit. This fixes some bugs where the GtkWindow accelerators were executed before the focused widget one. (#314431).
I reverted the patch as it broke cut and paste, I still need to find out why this happens.
*** Bug 573618 has been marked as a duplicate of this bug. ***
*** Bug 573564 has been marked as a duplicate of this bug. ***
Could this be related to bug 104116?
Changing component as a part of ongoing bug reorganisation work.
*** Bug 104116 has been marked as a duplicate of this bug. ***
We should come to a decision with this for 3.2, possibly involving GTK.
*** Bug 649116 has been marked as a duplicate of this bug. ***
*** Bug 647253 has been marked as a duplicate of this bug. ***
This became an important bug again, now that we use Ctrl+Delete by default. I couldn't manage to find a cleaner way of fixing it than resuming this old patch of mine, and finding out why copy/paste did not work properly - it turns out we ate the Ctrl+V keybinding on purpose to avoid the typeahead find search widget to pop up; while we can prevent this cleanly for the icon view, we can't really do that with the treeview, and need a bit of a hack. A comment in the code and my commit message explain in more detail why that's needed.