Closed
Bug 844922
Opened 12 years ago
Closed 12 years ago
gtk-key-theme-name="Emacs"' in .gtkrc breaks key bindings when focus is in an input text field (CTRL+W not working when focus is on an input text field)
Categories
(Core :: Widget: Gtk, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: marcoep, Unassigned)
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 Firefox/19.0 SeaMonkey/2.16
Build ID: 20130221175808
Steps to reproduce:
I was accustomed to CTRL+W working irrespective of the focus. Now, when the focus is on an input text field, it doesn't work any more :-(
It looks like a regression... In order to "unlock" the key binding, I have to either click elsewhere in a page or TAB away from the input field.
Actual results:
Focus is on an input text field (cursor blinking inside). Hit CTRL+W to close the tab: nothing happens.
Expected results:
The tab should have been closed.
Possibly related to Bug 672155.
WFM, in Windows.
> when the focus is on an input text field
Like the box I'm typing into at the moment, right?
If you restart in Safe Mode, does the problem persist?
(Help | Restart with Addons Disabled)
As a test, if you create a new, clean Profile, does the problem also happen there?
If you revert back to SeaMonkey 2.15.2 (I can assume it worked there?) is the problem resolved?
Oh, goodness, now I remember that between 2.14 and 2.15 I switched to Emacs key mode in my .gtkrc ...
gtk-key-theme-name="Emacs"
Indeed other key-bindings were behaving like in a console (when typing in a text field), and not like in Emacs as I was trying to do!
Removing the above offending line, gives me back Ctrl+W functionality.
So, this bug should be reformulated to something different, such as
'gtk-key-theme-name="Emacs"' in .gtkrc breaks key bindings when focus is in an input text field
...though it might well be a feature ;-)
Comment 4•12 years ago
|
||
> ...though it might well be a feature ;-)
I suspect that this bug is invalid (or working as designed). I'll move it somewhere where there are people who can better evaluate this bug.
Component: General → Widget: Gtk
Product: SeaMonkey → Core
Summary: SeaMonkey-2.16: CTRL+W not working when focus is on an input text field → gtk-key-theme-name="Emacs"' in .gtkrc breaks key bindings when focus is in an input text field (CTRL+W not working when focus is on an input text field)
Version: SeaMonkey 2.16 Branch → 19 Branch
Comment 5•12 years ago
|
||
Yes, we don't want a single Ctrl+W yanking text and closing the window.
Ctrl+W deleting word backward is not really emacs behaviour, but is what other GTK apps do with emacs key bindings.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
It seems this bug reappeared in quantum.
I'd like to elaborate a bit more on this issue. I've been using the
gtk2 key bindings pasted at bottom since years (that include the C-w
delete word backwards), lately I translated them to gtk3. They work OK
on most gtk2 applications, on gtk3 depending on which application you
use the behavior is more or less buggy.
On firefox, as long as I can recall, have always worked the "text-entry"
ones (the first group).
How to reproduce it
-------------------
Since this key binding is also included in the Emacs theme that gtk
installs by default (/usr/local/share/themes/Emacs), you can reproduce
it easily by doing:
$ echo "gtk-key-theme=Emacs" >> ~/.config/gtk-3.0/settings.ini
Then restart firefox, focus a text box or text area in any web page and
press Ctrl-W. It should delete a word backwards, not to close the
window or tab.
# ~/.gtkrc-2.0
binding "gtk-vi-text-entry"
{
bind "<ctrl>u" { "delete-from-cursor" (paragraph-ends, -1) }
bind "<ctrl>h" { "delete-from-cursor" (chars, -1) }
bind "<ctrl>w" { "delete-from-cursor" (word-ends, -1) }
bind "<ctrl>b" { "move-cursor" (paragraph-ends, -1, 0) }
bind "<ctrl>e" { "move-cursor" (paragraph-ends, 1, 0) }
}
binding "gtk-vi-tree-view"
{
bind "j" { "move-cursor" (display-lines, 1) }
bind "k" { "move-cursor" (display-lines, -1) }
bind "l" { "move-cursor" (logical-positions, 1) }
bind "h" { "move-cursor" (logical-positions, -1) }
bind "slash" { "start-interactive-search" () }
}
binding "gtk-vi-menu"
{
bind "j" { "move-current" (next) }
bind "k" { "move-current" (prev) }
bind "l" { "move-current" (child) }
bind "h" { "move-current" (parent) }
}
class "GtkEntry" binding "gtk-vi-text-entry"
class "GtkTreeView" binding "gtk-vi-tree-view"
class "GtkMenuShell" binding "gtk-vi-menu"
# End of ~/.gtkrc-2.0
/*
* ~/.themes/Vi/gtk-3.0/gtk-keys.css
*/
@binding-set gtk-vi-text-entry
{
bind "<ctrl>b" { "move-cursor" (paragraph-ends, -1, 0) };
bind "<ctrl>e" { "move-cursor" (paragraph-ends, 1, 0) };
bind "<ctrl>u" { "delete-from-cursor" (paragraph-ends, -1) };
bind "<ctrl>h" { "delete-from-cursor" (chars, -1) };
bind "<ctrl>w" { "delete-from-cursor" (word-ends, -1) };
}
@binding-set gtk-vi-text-view
{
bind "<ctrl>f" { "move-cursor" (display-lines, 10, 0) };
bind "<ctrl>b" { "move-cursor" (display-lines, -10, 0) };
bind "<ctrl>d" { "move-cursor" (display-lines, 5, 0) };
bind "<ctrl>u" { "move-cursor" (display-lines, -5, 0) };
bind "<ctrl>e" { "move-cursor" (display-lines, 1, 0) };
bind "<ctrl>y" { "move-cursor" (display-lines, -1, 0) };
}
@binding-set gtk-vi-tree-view
{
bind "j" { "move-cursor" (display-lines, 1) };
bind "k" { "move-cursor" (display-lines, -1) };
bind "l" { "move-cursor" (logical-positions, 1) };
bind "h" { "move-cursor" (logical-positions, -1) };
}
@binding-set gtk-vi-menu
{
bind "j" { "move-current" (next) };
bind "k" { "move-current" (prev) };
bind "l" { "move-current" (child) };
bind "h" { "move-current" (parent) };
}
entry { -gtk-key-bindings: gtk-vi-text-entry; }
textview { -gtk-key-bindings: gtk-vi-text-entry, gtk-vi-text-view; }
treeview { -gtk-key-bindings: gtk-vi-tree-view; }
menushell { -gtk-key-bindings: gtk-vi-menu; }
/*
* End of gtk-keys.css
*/
You need to log in
before you can comment on or make changes to this bug.
Description
•