Closed
Bug 254903
Opened 20 years ago
Closed 20 years ago
ctrl+b should trigger bookmarks even from text areas
Categories
(Firefox :: Disability Access, defect, P5)
Tracking
()
VERIFIED
DUPLICATE
of bug 257405
People
(Reporter: asa, Assigned: aaronlev)
References
(Blocks 1 open bug)
Details
(Whiteboard: l10n impact unknown)
Ctrl+B doesn't work reliably. It appears you have to focus the content area first.
Comment 1•20 years ago
|
||
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!)
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 2•20 years ago
|
||
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.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Comment 3•20 years ago
|
||
(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.
Comment 4•20 years ago
|
||
(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.
Comment 6•20 years ago
|
||
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.
Comment 7•20 years ago
|
||
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.
Comment 9•20 years ago
|
||
Well, I use _some_, sure. But Ctrl+B?
Assignee | ||
Comment 10•20 years ago
|
||
*** This bug has been marked as a duplicate of 72352 ***
Status: REOPENED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → DUPLICATE
Comment 11•20 years ago
|
||
This is not a duplicate of a bug requesting a pref.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Assignee | ||
Comment 12•20 years ago
|
||
(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.
Comment 13•20 years ago
|
||
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.
Reporter | ||
Comment 14•20 years ago
|
||
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.
Flags: blocking-aviary1.0?
Summary: ctrl+b and focus problem → ctrl+b should trigger bookmarks even from text areas
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.
Reporter | ||
Comment 16•20 years ago
|
||
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.
Assignee | ||
Comment 17•20 years ago
|
||
If hardcore emacs/readline folks are not satisfied perhaps a Firefox extension for their bindings can be devised.
Comment 18•20 years ago
|
||
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?
Comment 19•20 years ago
|
||
> 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.
Comment 21•20 years ago
|
||
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 ***
Status: REOPENED → RESOLVED
Closed: 20 years ago → 20 years ago
Flags: blocking-aviary1.0?
Resolution: --- → DUPLICATE
Updated•20 years ago
|
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•