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)

Product:
Firefox
Component:
Disability Access
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
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.
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
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 → ---
(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 ***
Status: REOPENED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → DUPLICATE
This is not a duplicate of a bug requesting a pref.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
(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.
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.
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?
Whiteboard: l10n impact unknown
Blocks: firekey
Priority: -- → P5
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
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.