Closed Bug 29941 Opened 25 years ago Closed 24 years ago

keyboard shortcuts for back/forward should use arrows, not brackets

Categories

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: j, Assigned: don)

References

Details

(Whiteboard: [note to german: update spec]) 

I realize the shortcuts are not enabled yet (M14), but I have noticed that they 
will be ctl-] & ctl-[ for "back" and "forward". I think they should be the same 
as in netscape, i.e. alt-> and alt-< for forward and back, respectively. The 
change seems arbitrary, and the [ & ] keys are much further of a reach on the 
keyboard from the alt key. I think the alt-arrow keys are also used in M$ IE, so 
a lot of users will be forced to change if this new scheme is implemented.
Sarah, did you have a bug like this that was already fixed?

yes...and it was recently fixed... but cannot seem to find it after searching a
bit --claudius, d'you remember the bug number? if so, we can dup this one. thx!
28904?

yup, that one! :-)

*** This bug has been marked as a duplicate of 28904 ***
Status: UNCONFIRMED → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
Verified dupe. thanks.
Status: RESOLVED → VERIFIED
Er, uh, I had not even noticed the direction mismatch. I was commenting that the 
mapping of those functions should be to the cursor (arrow) keys instead of the 
bracket keys, in order to operate like all the other browsers I have used. I 
have seen several comments on /. which agree. It matters to people who use 
keyboard shortcuts because of RSI, etc. Mousers don't care.
Shuang?
Status: VERIFIED → UNCONFIRMED
Resolution: DUPLICATE → ---
just to set the record straight. 4.x used the arrows on Linux and Win, and used the brackets on Mac. So it looks like Seamonkey 
'borrowed' the mac shortcut, it wasn't just pulled out of thin air. Changing summary so as not to confuse with that other bug 
anymore.
this basically amounts to and RFE, no? Confirming this bug as it is valid.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: keyboard shortcuts for forward & back should follow established mapping → keyboard shortcuts for forward & back should map to arrows, not brackets
reassign it to german.
Assignee: shuang → german
QA Assigning non-confidential New/Assigned User Interface: Design Feedback bugs 
to Matthew Thomas (mpt@mailandnews.com).

Matthew Thomas is now the QA owner for the User Interface: Design Feedback 
component. (Bugs that involve UI issues in the Netscape-branded Mozilla browser 
should continue be QA assigned to elig@netscape.com.)
QA Contact: elig → mpt
MacOS 4.x also uses Cmd+Left/Right for Back/Forward -- which is technically 
misappropriating Apple-reserved key combinations, but it seems to work. So 
`Seamonkey "borrowed" the mac shortcut' should be `Seamonkey "borrowed" *one of* 
the Mac shortcuts'.

But more to the point, [ and ] aren't localization-safe, so you shouldn't use 
them in keyboard shortcuts. See bug 36048.
Blocks: 36048
Hardware: PC → All
Summary: keyboard shortcuts for forward & back should map to arrows, not brackets → keyboard shortcuts for back/forward should use arrows, not brackets
set to M18 so we can have a date for conclution. German still should be the 
owner of the bug till he gives solution. So after PR2 then.
Target Milestone: --- → M18
*** Bug 37655 has been marked as a duplicate of this bug. ***
37655 was marked [nsbeta2+] 6/1
and I just marked it a dupe of this, so I'd like to mark this bug with 
[nsbeta2+] 6/1
If someone decides to remove these flags, I think it should get relnotes.
Keywords: nsbeta2
Whiteboard: [nsbeta2+] 6/1
removing nsbeta2+ designation since I don't believe 37655 to be a dup of this
Whiteboard: [nsbeta2+] 6/1
Keywords: nsbeta2
Nominating nsbeta3.  The [ and ] keys aren't on all (int'l) keyboards (see bug
28904), and they aren't at all convenient on some US ones (a Kinesis, where
they're in the top corners (one in each), or the Dvorak layout, where they're
where - and ] are).
Keywords: nsbeta3
adding kurt to cc list due to his comment in bug 28904. matthew, d'you want to
keep this bug here, or move over to the Keyboard Navigation component?
Seems perfectly straightforward to me -- this is one of the things Slashdot users 
have been complaining about the most after the release of each milestone -- but, 
as always, it's not my decision.

Putting in Keyboard Navigation component, QA to Sarah, CCing Keyboard Navigation 
component owner so he can CC the relevant programmer ... but leaving as assigned 
to German, given that `German still should be the owner of the bug till he gives 
solution'.
Component: User Interface: Design Feedback → Keyboard Navigation
QA Contact: mpt → sairuh
I believe the original motivation for this old shortcut was to enable users with 
smll keybaords (e.g portables) which do *not* have arrow keys to have keyboard 
access  to this navigation. I agree so that the mapping would be much clearer 
using the arrow keys and if we assume that the majority of users today have 
extended kbs than this change is a good thing.
I also agree with the comments on localized keyboards that do not have that 
advantagous mapping for "[" and "]"
assinging to don's team for now as this seems its browser related.
Assignee: german → don
Whiteboard: [note to german: update spec]
I don't know of many laptop keyboards these days that don't have arrow keys.  
Number pads, sure.
ben fixed this a couple of days ago...
Status: NEW → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED
German is the Spec updated? if so, please enter the url here and update the 
status, thank you.
Keywords: verifyme
I'd love to verify this, but I can't.  Running the 2000080120 build on NT4, the 
Alt+Left and Alt+Right shortcut keys work, but the menu items have "Alt+" as the 
shortcut key.  This is for the Go > Back, Forward, and Home menu items.  All 
other menu items seem to display the proper shortcut key, so I think that this 
is a problem that's specific to this bug.

I'm going to re-open this.  Someone bitch at me if I did a Bad Thing.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
i presume the supposed fixes went into the trunk, as i don't see 'em with
today's bits. (won't have a chance to vrfy Dean's observation as i'm immersed
with branch joy this week.)
I commented on that at the end of bug 46803, and Ben responded:

"That's a separate bug. The menu code should be reading the key binding 
specified in its key attribute and filling the accelerator portion 
appropriately. Sounds like it's not doing it for special keys like VK_HOME. 

Anyhow, after my little mishap with an entity on linux last night, I've finally 
got this all working... so closing again."

Since that seems like it might be a more general keybinding issue, and this bug 
has already been littered with other comments, I'm going to split that off as a 
separate bug.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
So really, this and bug 46803 are one and the same.  Anyone know if there's a 
bug filed on what Ben mentioned?
Duh.  Helps if I read sairuh's comment.  Verified using 2000080120 on NT.  
Somone with Mac and Linux want to verify?
bug 41325 blocks verification on the mac.

my wm [afterstep] keybindings are clobbering the shortcuts on linux. timeless,
would you be able to vrfy this?
Depends on: 41325
vrfy
ctrl+left and ctrl+right work on solaris intel [cvs build from yesterday].
Go still says 'ctrl+' because of bug 47426. [Adding dependency]
German I still want this bug to have the url for the spec so I can verify that 
the spec says arrows instead of brackets.
Status: RESOLVED → VERIFIED
Depends on: 47426
Keywords: verifyme
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.