Ctrl+B doesn't work reliably. It appears you have to focus the content area first.
Asa, on Linux there are various keyboard accelerators (hotkeys) which use Emacs bindings *while in a text area or input field* instead of the regular mozilla ones. for example, Ctrl+B: moves caret one char to left --but if focus is *not* in a textfield, then this shortcut will bring up the Bookmarks Sidebar. so this looks to be invalid. (feel free to ping me if this is still confusing!)
This should be reconsidered since we went in favor of the browser shortcut rather than the editor shortcut with ctrl+w. bookmarks is a very common task and the browser functionality should probably overrule the editor functioanlity on this one.
(In reply to comment #2) > This should be reconsidered since we went in favor of the browser shortcut > rather than the editor shortcut with ctrl+w. bookmarks is a very common task and > the browser functionality should probably overrule the editor functioanlity on > this one. unless I'm misunderstanding you, Ctrl+W on Linux in textfields still follows the emacs keybinding of deleting from the caret to the beginning of the line --it doesn't close the window/tab. unless that changed recently (I'm using 20040804-0.9+), or is only changed on the trunk. I'm not sure if we should change all of the emacs bound shortcuts, or just some of them. I wouldn't mind changing these, as long as we're consistent, ie, change all or none, but not just some.
(In reply to comment #2) > This should be reconsidered since we went in favor of the browser shortcut > rather than the editor shortcut with ctrl+w. bookmarks is a very common task and > the browser functionality should probably overrule the editor functioanlity on > this one. unless I'm misunderstanding you, Ctrl+W on Linux in textfields still follows the emacs keybinding of deleting from the caret to the beginning of the line --it doesn't close the window/tab. unless that changed recently (I'm using 20040804-0.9+), or is only changed on the trunk. I wouldn't mind changing the emacs bound shortcuts, as long as we're consistent, ie, change all or none, but not just some.
please disregard comment 3. sigh, my bad.
Given how often this confuses me, yes, I think we should make our shortcuts work always. Are Emacs shortcuts (especially for moving the cursor!) really needed? I mean, that's why we have arrow keys, and Home/End keys, etc.
The emacs/readline bindings are much easier to type (without moving your hand from the home position, or looking at the keyboard, or having to press Fn on a laptop), and have been standard on unix platforms for over a decade (some of them also on windows), and OS X has them now -- mozilla just added them for OS X a few weeks ago since users asked for them. Lots of people still use them. Perhaps two alternate sets of bindings, so the user could choose to have all or none? Unfortunately XBL can't switch key bindings at runtime, AFAIK (only at startup).
I use some of the emacs keybindings as well (mostly C-K and C-U). However, I think it would be nice if hitting "Esc" unfocused a textarea / text input / URL bar so that I could use the window keybidings.
Well, I use _some_, sure. But Ctrl+B?
*** This bug has been marked as a duplicate of 72352 ***
This is not a duplicate of a bug requesting a pref.
(In reply to comment #11) > This is not a duplicate of a bug requesting a pref. There are different opinions on how to take care of this. My opinion is is to use a pref, exposed on Linux but still available on other platforms as a hidden pref. Basically I agree with Sarah "I wouldn't mind changing these, as long as we're consistent, ie, change all or none, but not just some." and yet I agree with Akkana that we need them. The current state of trying to walk the fence between emacs and not-emacs isn't working that well. Do you agree that the pref solution is the right one? If not, what's your proposal? I want the bug summary to at least reflect a more global problem and solution -- there's not much point in having a bunch of tweak bugs for our current half-baked solution -- unless I see a well thought out plan but I doubt that will ever happen. Especially not with keyboard conflicts for things like Ctrl+W.
The pref "solution" is not a solution, since no real user will change the pref. Effectively, a pref merely means yet more code bloat, dramatically reduced testing for the non-default code branch, and that the bug is really "fixed" by doing whatever the default for the pref is. (And that's with a pref that has UI -- for a pref without UI, the difference is even more pronounced.) What we should do, IMHO, is support the key bindings we do now, except where those conflict with bindings that would work outside text fields. In other words, don't overload the key bindings. If the menu says Ctrl+B is something, that's what it should do, whether a text field has focus or not.
I agree with Ian here. The answer is to say that browser shotcuts take precedent over ancient emacs editor bindings. We're not using emacs! We're using Firefox. I'm a linux user and I've never even touched emacs and never will. There may have been a time when near every linux user was an emacs user, but I suspect that I'm no longer in the minority given Linux's recent (last 5 years) growth spurt on the desktop. If we can hold on to a few oldschool keybindings for the old unix people, fine, but not where they conflict with primary browser functionality.
I don't know why people keep talking about this like it's an emacs issue; ctrl-W for delete-word-left is a _readline_ binding, not an emacs binding, and ctrl-B is both. If you use a shell on Linux -- and I suspect you do, even with the growth in the last 5 years -- you can easily end up expecting ctrl-B/F to move your cursor around. If you're on a laptop with crappy arrow-key placement, you're probably even glad that it does. Trumping text-navigation bindings with "core browser functionality" bindings sounds fine, I guess, but it leaves me with some questions: - are we going to keep whittling away the keybindings as we add new accelerators for browser features? - do we expect our textarea bindings to be the same across our apps and toolkit (I hope so, personally)? One solution to both those issues is to nail down a list of text-manipulation keybindings for our textareas, and make them out of bounds for accelerators, at least on Unix. Given our oft-woeful focus story, removing ctrl-W from the list of textarea bindings is probably the right thing, but we'd best do it ASAP, so we don't end up with (more) data loss after people get accustomed to it in Fx1.0.
Shaver, how about we approach it from both directions. We can try to nail down a set of text area key bindings and not add new browser shortcuts that usurp those, but we also look at it from the browser side and we define a set of browser features or actions that are important enough that they should be consistent regardless of whether the focus is in a text area or not. I think ctrl+b belongs on the browser list and not the text area list. I agree that we should nail all of this down before we ship 1.0.
If hardcore emacs/readline folks are not satisfied perhaps a Firefox extension for their bindings can be devised.
Whittling away at the bindings bit by bit is infuriating, since as a user you never know what's going to work as it used to, versus what's going to pop up some surprise window you didn't want and didn't think you asked for. Just yesterday I was hearing a bunch of people complain about how they'd switched away from xchat for doing that (for C-B and C-F, in fact) and I would have except it turned out to be easy to hack back into the source. Re making it a pref: I know of no way to make xbl bindings follow a pref (short of adding a bunch of pref-checking code right in the middle of the xbl key handling code, which I doubt anyone wants to do). I've tried to say that in bug 72352, but nobody there seems interested in implementation details. I suspect it has to be done at startup, probably with something like an alternate xbl binding file. It could of course look like a pref to the user, except they'd probably have to restart to see the change. (Ideally we'd let the user customize specific bindings, but that's a pipe dream which would require both XUL and XBL to allow runtime key binding changes, with menus updating to reflect the new bindings instead of being hardwired as they are now.) 100% agreement with Shaver that it's not an emacs issue. Most of the bindings have existed in every Unix shell (including Mac OS X ones), all Unix GUI toolkits (until gtk2, which still has it but makes it optional) and readline, the library that many Unix apps use to read input. > no real user will change the pref It may be true that users who don't use the bindings won't look for a key binding pref, and if we made this optional I can see an argument for defaulting to being windows-like.I guarantee that when users who have been using C-B in browser text fields since Netscape 1 see it disappear, at least some of them will go looking for a way to change it back. > If the menu says Ctrl+B is something, that's what it should do That's bug 71779. I hope we aren't going to cripple editing for people who use these bindings just because no one is fixing XBL/XUL/focus bugs?
> Whittling away at the bindings bit by bit is infuriating I agree that, as others have said, we should decide which bindings we are going to support, and keep them once and for all. But we shouldn't have bindings that are so context sensitive that they work when a radio button has focus but not when a text field has focus, especially in cases like the location bar, which gets focus the moment you open a new tab. Case study: Open bookmarks with Ctrl+B, then open new tab with Ctrl+T. That works. Now do the apparently exact same thing, but backwards: Open a new tab with Ctrl+T, and open bookmarks with Ctrl+B. Nothing happens on the second keystroke (at all, since the location bar is empty), and yet the user is left with no explanation. This happens to me a _lot_. >> If the menu says Ctrl+B is something, that's what it should do > > That's bug 71779. I hope we aren't going to cripple editing for people who > use these bindings just because no one is fixing XBL/XUL/focus bugs? Please don't tell me you want the menu to change what it claims the keybindings are depending on what I have focussed when I open the menu. That would be even less usable than what we have now. What we need to do is make a list of what keybindings we are going to support, and then support them reliably, everywhere. Modal UI (that is, UI that changes based on what "mode" the user is in -- textarea focussed, content area focussed, etc) is wildly recognised as being bad UI.
Would any patches here affect l10n?
This was fixed by bug 257405 before 1.0PR. It least it WFM here on my Linux GTK2 build. *** This bug has been marked as a duplicate of 257405 ***