After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 314431 - gtk_window_activate_key messes up keybindings
gtk_window_activate_key messes up keybindings
Status: RESOLVED FIXED
Product: nautilus
Classification: Core
Component: Location Bar
2.91.x
Other All
: High normal
: 3.2
Assigned To: Nautilus Maintainers
Nautilus Maintainers
AP4
: 104116 345528 369636 520475 573564 573618 647253 649116 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-08-24 22:38 UTC by Wouter Bolsterlee (uws)
Modified: 2011-06-11 16:27 UTC
See Also:
GNOME target: ---
GNOME version: 2.91/3.0


Attachments
patch (4.32 KB, patch)
2008-02-29 17:03 UTC, Cosimo Cecchi
none Details | Review
patch v2 (1.43 KB, patch)
2008-03-01 00:54 UTC, Cosimo Cecchi
none Details | Review
patch v3 (3.06 KB, patch)
2008-03-31 08:37 UTC, Cosimo Cecchi
needs-work Details | Review

Description Wouter Bolsterlee (uws) 2005-08-24 22:38:03 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.
Comment 1 Wouter Bolsterlee (uws) 2005-08-24 22:38:52 UTC
Forgot to add: the dialog that pops up after pressing Control-L in spatial mode
works as intended.
Comment 2 Christian Neumair 2005-09-03 13:59:39 UTC
Usability team, what do you think? Should we have a preference which forces the
Nautilus location entry to obey some common shell keybindings?
Comment 3 Olav Vitters 2005-09-03 14:10:36 UTC
Could it follow the gtk key (what you change to Emacs). It is in gconf under
/desktop/gnome/interface/gtk_key_theme.
Comment 4 Christian Neumair 2005-09-03 14:26:25 UTC
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.
Comment 5 Wouter Bolsterlee (uws) 2005-09-03 19:58:42 UTC
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.
Comment 6 Calum Benson 2006-04-26 17:14:56 UTC
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
Comment 7 Calum Benson 2006-04-26 17:45:58 UTC
Apologies for spam... marking as AP4 to reflect accessibility impact.
Comment 8 Christian Neumair 2006-06-21 19:55:56 UTC
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).
Comment 9 Christian Neumair 2006-06-21 19:56:04 UTC
*** Bug 345528 has been marked as a duplicate of this bug. ***
Comment 10 Wouter Bolsterlee (uws) 2006-10-06 13:23:38 UTC
Any progress on this one? Epiphany has some code that fixes this issue (it was taken from Galeon).
Comment 11 Jimmy Angelakos 2007-03-25 10:20:06 UTC
This is still not fixed as of Nautilus 2.16.1 (Ubuntu Edgy).
Comment 12 Wouter Bolsterlee (uws) 2008-01-17 11:01:10 UTC
(/me cries silently)
Comment 13 Cosimo Cecchi 2008-02-29 16:27:35 UTC
Still there with 2.21.92, modifying fields.
Comment 14 Cosimo Cecchi 2008-02-29 17:03:47 UTC
Created attachment 106280 [details] [review]
patch

This is adapted from Epiphany, works just fine in my testing.
Comment 15 Cosimo Cecchi 2008-03-01 00:43:10 UTC
*** Bug 369636 has been marked as a duplicate of this bug. ***
Comment 16 Cosimo Cecchi 2008-03-01 00:54:26 UTC
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).
Comment 17 Cosimo Cecchi 2008-03-05 08:49:19 UTC
*** Bug 520475 has been marked as a duplicate of this bug. ***
Comment 18 Alexander Larsson 2008-03-14 14:49:05 UTC
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.  
Comment 19 Owen Taylor 2008-03-24 19:19:12 UTC
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.
]
Comment 20 Alexander Larsson 2008-03-28 14:06:26 UTC
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.
Comment 21 Cosimo Cecchi 2008-03-31 08:37:30 UTC
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.
Comment 22 Christian Neumair 2008-04-27 17:35:28 UTC
Cosimo: Thanks for your work, please commit the patch to trunk and to the GNOME 2.22 branch.
Comment 23 Cosimo Cecchi 2008-04-27 18:02:40 UTC
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).
Comment 24 Cosimo Cecchi 2008-05-05 13:21:32 UTC
I reverted the patch as it broke cut and paste, I still need to find out why this happens.
Comment 25 Cosimo Cecchi 2009-03-02 16:40:43 UTC
*** Bug 573618 has been marked as a duplicate of this bug. ***
Comment 26 Cosimo Cecchi 2009-03-02 16:41:05 UTC
*** Bug 573564 has been marked as a duplicate of this bug. ***
Comment 27 Sense Hofstede 2009-12-22 12:21:31 UTC
Could this be related to bug 104116?
Comment 28 Allan Day 2010-06-21 20:37:26 UTC
Changing component as a part of ongoing bug reorganisation work.
Comment 29 Cosimo Cecchi 2010-07-04 23:06:24 UTC
*** Bug 104116 has been marked as a duplicate of this bug. ***
Comment 30 Cosimo Cecchi 2011-03-31 19:25:21 UTC
We should come to a decision with this for 3.2, possibly involving GTK.
Comment 31 Cosimo Cecchi 2011-05-23 20:24:41 UTC
*** Bug 649116 has been marked as a duplicate of this bug. ***
Comment 32 Cosimo Cecchi 2011-05-23 20:26:11 UTC
*** Bug 647253 has been marked as a duplicate of this bug. ***
Comment 33 Cosimo Cecchi 2011-05-23 20:56:41 UTC
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.