Closed Bug 260188 Opened 20 years ago Closed 20 years ago

emacs/readline keybindings are off by default (ctrl+u in address bar views source)

Categories

(Firefox :: Keyboard Navigation, defect)

Other
Linux
defect
Not set
trivial

Tracking

()

VERIFIED DUPLICATE of bug 260572

People

(Reporter: postmodern.mod3, Assigned: bugs)

References

Details

(Whiteboard: See comment 18 and comment 23)

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; rv:1.7.3) Gecko/20040917 Firefox/0.10
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; rv:1.7.3) Gecko/20040917 Firefox/0.10

ctrl+u in address bar views source and dosn't clear the contents of the address bar.

Reproducible: Always
Steps to Reproduce:
1. click in address box
2. ctrl+u
3.

Actual Results:  
invokes "view source" function

Expected Results:  
clears address bar
Change your emacs keybinding pref and it should work fine. If not, then reopen.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
*** Bug 261144 has been marked as a duplicate of this bug. ***
*** Bug 262621 has been marked as a duplicate of this bug. ***
*** Bug 263031 has been marked as a duplicate of this bug. ***
(In reply to comment #4)
> http://kb.mozillazine.org/index.phtml?title=Emacs_Keybindings_(Firefox)

That is singularly unhelpful. All it says is
   "(There is currently no text in this page)"

I found another page (via google) that was almost helpful
which stated:
 
  Firefox uses the GTK setting to determine whether
  Emacs-like/Readline-like keybindings are active in text fields. To
  enable these keybindings, add to ~/.gtkrc-2.0 the line:
 
  gtk-key-theme-name = "Emacs"

Unfortunately that did not work for me. (Mozilla still behaves as expected:
I am using redhat 8 and 9).

I have searched both in firefox and mozilla for something in the "preferences"
pages, but without success.

I tried the help button and looked in the documentation for Firefox.
There was a section headed 'Firefox Keyboard Shortcuts' but merely listed
defaults without even mentioning the possibility of changing them, let alone
saying how.

Has firefox now been taken over by designers who 'know' what's good for everyone
else?

I think this is not an 'invalid' bug report.

Aaron
==
www.cs.bham.ac.uk/~axs
I second the motion! Sure one can argue its just an issue of setting your key
binds in a hidden config file but this is un-userfriendly. Most users have lived
with the ctrl-u clears the address bar since Netscape. This functionality is
everywhere in the gnome/kde environments. Firefox should conform to this spec so
not to annoy users and force them to hunt for hidden configuration files.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
> All it says is "(There is currently no text in this page)"

Bugzilla cuts the last ")" off of the URL, turning it into a 404.
*** Bug 264232 has been marked as a duplicate of this bug. ***

*** This bug has been marked as a duplicate of 189615 ***
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → DUPLICATE
*** Bug 265913 has been marked as a duplicate of this bug. ***
This could be fixed without fixing bug 189615, so this isn't a dup.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Summary: ctrl+u in address bar views source → ctrl+u in address bar views source. (emacs/readline keybindings are off by default)
Based on this, bug 189615 is most likely fixed. Can someone confirm?
Status: UNCONFIRMED → NEW
Component: Location Bar and Autocomplete → Keyboard Navigation
Ever confirmed: true
Summary: ctrl+u in address bar views source. (emacs/readline keybindings are off by default) → emacs/readline keybindings are off by default (ctrl+u in address bar views source)
Comment #6 suggests editing ~/.gtkrc-2.0 to work around this bug. Comment #6
also reports that this workaround did not actually work for him. I'm seeing the
same behaviour. I edited ~/.gtkrc-2.0 to add the one line. I've confirmed with
strace that firefox reads this file:
...
lstat64("/etc/gtk-2.0/gtkrc", 0x7fffece0) = -1 ENOENT (No such file or directory)
access("/etc/gtk-2.0/gtkrc.en_US", F_OK) = -1 ENOENT (No such file or directory)
access("/etc/gtk-2.0/gtkrc.en", F_OK)   = -1 ENOENT (No such file or directory)
lstat64("/home/sarnold/.gtkrc-2.0", {st_mode=S_IFREG|0644, st_size=29, ...}) = 0
open("/home/sarnold/.gtkrc-2.0", O_RDONLY|O_LARGEFILE) = 19
read(19, "gtk-key-theme-name = \"Emacs\"\n", 4000) = 29
read(19, "", 4000)                      = 0
close(19)                               = 0
access("/home/sarnold/.gtkrc-2.0.en_US", F_OK) = -1 ENOENT (No such file or
directory)
access("/home/sarnold/.gtkrc-2.0.en", F_OK) = -1 ENOENT (No such file or directory)
access("/home/sarnold/.themes/Default/gtk-2.0/gtkrc", F_OK) = -1 ENOENT (No such
file or directory)
access("/usr/share/themes/Default/gtk-2.0/gtkrc", F_OK) = 0
lstat64("/usr/share/themes/Default/gtk-2.0/gtkrc", {st_mode=S_IFREG|0644,
st_size=69, ...}) = 0
open("/usr/share/themes/Default/gtk-2.0/gtkrc", O_RDONLY|O_LARGEFILE) = 19
read(19, "#\n# This theme is the default th"..., 4000) = 69
...


I'm seeing this behaviour with Debian packages
mozilla-firefox_0.10.1+1.0PR-4_powerpc and libgtk2.0-0_2.4.13-1_powerpc.

Any other suggestions to work around this problem? Thanks
Why are people editing config files instead of just using the GNOME control
center to set their keyboard settings in GTK?
Because not everyone is using gnome :)

People using gnome should indeed use the control center or set if via gconf,
otherwise it will probably not work. People not using gnome should use
.gtkrc-2.0. It works fine everywhere I tested (with both gnome and non-gnome
environnements)
(In reply to comment #15)
> Why are people editing config files instead of just using the GNOME control
> center to set their keyboard settings in GTK?

Boris, I don't use any other GNOME application. I don't have GNOME control panel
installed. I suppose installing the GNOME control panel is an option. However,
as firefox worked fine for me for weeks (and mozilla for years before it)
without any GNOME installed, I -really- don't want to install a whole mess of
junk I won't use except to work around what I consider a misfeature in the first
place. :)
I found the magic lines required to work around this problem. People who came
here looking for a solution, add the following two lines to your ~/.gtkrc-2.0 file:
include "/usr/share/themes/Emacs/gtk-2.0-key/gtkrc"
gtk-key-theme-name = "Emacs"


Make sure the included file exists. It may move around from distribution to
distribution. I found both lines are required.

Restart firefox. Enjoy your old keybindings again. :)
*** Bug 266748 has been marked as a duplicate of this bug. ***
*** Bug 268886 has been marked as a duplicate of this bug. ***
*** Bug 268964 has been marked as a duplicate of this bug. ***
*** Bug 269752 has been marked as a duplicate of this bug. ***
(In reply to comment #18)
> I found the magic lines required to work around this problem. People who came
> here looking for a solution, add the following two lines to your ~/.gtkrc-2.0
file:
> include "/usr/share/themes/Emacs/gtk-2.0-key/gtkrc"
> gtk-key-theme-name = "Emacs"

That did not work for me. When I looked in the file
   /usr/share/themes/Emacs/gtk-2.0-key/gtkrc

I found no mention of ctrl u. So I searched via google for
  gtkrc emacs bind delete

and found this link
  http://cvs.gnome.org/viewcvs/gtk+/gtk/gtkrc.key.emacs?rev=1.3

and in there I found the following lines:
  #
  # Some non-Emacs keybindings people are attached to
  #
  bind "<ctrl>u" {
     "move-cursor" (paragraph-ends, -1, 0)
     "delete-from-cursor" (paragraph-ends, 1)
  }
  bind "<ctrl>h" { "delete-from-cursor" (chars, -1) }
  bind "<ctrl>w" { "delete-from-cursor" (word-ends, -1) }

Adding those and restarting firefox solved the problem.

Maybe that will finally allow everyone to get satisfaction?

Are those really not standard Emacs key bindings? (I am not an
Emacs user, though I am used to CTRL+u deleting to start of
line going back many years on DEC machines and in most unix
and linux shells I have used. I thought it was also an Emacs
convention because Emacs was developed by people who came from
the same background. Perhaps the development branched at some point.)

Aaron
Whiteboard: See comment 18 and comment 23
Come on, this in not an Emacs thing, it's a general Unix/Linux thing: all shells
I know use it, vi and Emacs respect it too, is this so hard to repair this?
And what is the advantage gained by breaking this

To me it seems fairly obvious to keep ctrl-u to delete the current line *like it
has been in all previous Firefox and Mozilla versions*
Next to that: to me it seems intiutive to makes this context sensitive, erase
line in address and search bar, source in page.

It seems wrong that people have to hack around to fix this. I think Wintendo
people gained nothing by having ctrl-u opening a source box in address or search
context.
(In reply to comment #24)
> To me it seems fairly obvious to keep ctrl-u to delete the current line *like it
> has been in all previous Firefox and Mozilla versions*

If you read comment 18 and comment 23, you'll see that this is now user
configurable. Firefox relies on the system configuration to determine the
behaviour. Since this system setting has nothing to do with Firefox, I
personally think that this should be marked invalid.
On *nix, we're a GNOME/GTK2 app at this point, so we will respect the same
preference as other GNOME/GTK2 apps.  If you want these keybindings, set up your
system to use them.  However, where a system preference exists, we will use that
instead of rolling our own.  Same logic applies to proxy settings, we should be
using system prefs instead of forcing users to set things twice.

Since this bug has already been spammed to death, duping to the less spam-tastic
dupe-catcher.

The main rationale behind the changes (and this is why GNOME moved away from
them as well) is that having shortcuts do different things depending on where
focus is almost always leads to user confusion.  Some of the Mozilla people who
advocated the heaviest for using the GNOME pref are avid, long-time emacs users.
 Even they found the behaviour frustrating, and argued that even though it might
hurt them in the short term, the overall user experience would be better for the
change.

If someone wants to carry on the debate, please take it to private email as this
is a decision that we're not going to revisit.

*** This bug has been marked as a duplicate of 260572 ***
Status: NEW → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
*** Bug 300478 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.