All users were logged out of Bugzilla on October 13th, 2018

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




19 years ago
18 years ago


(Reporter: j, Assigned: don)


Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


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



19 years ago
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.

Comment 1

19 years ago
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!

Comment 3

19 years ago
yup, that one! :-)

*** This bug has been marked as a duplicate of 28904 ***
Last Resolved: 19 years ago
Resolution: --- → DUPLICATE

Comment 5

19 years ago
Verified dupe. thanks.

Comment 6

19 years ago
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.

Comment 7

19 years ago
Resolution: DUPLICATE → ---

Comment 8

19 years ago
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 
this basically amounts to and RFE, no? Confirming this bug as it is valid.
Ever confirmed: true
Summary: keyboard shortcuts for forward & back should follow established mapping → keyboard shortcuts for forward & back should map to arrows, not brackets

Comment 9

19 years ago
reassign it to german.
Assignee: shuang → german

Comment 10

19 years ago
QA Assigning non-confidential New/Assigned User Interface: Design Feedback bugs 
to Matthew Thomas (

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
QA Contact: elig → mpt

Comment 11

19 years ago
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

Comment 12

19 years ago
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

Comment 13

19 years ago
*** Bug 37655 has been marked as a duplicate of this bug. ***

Comment 14

19 years ago
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

Comment 15

19 years ago
removing nsbeta2+ designation since I don't believe 37655 to be a dup of this
Whiteboard: [nsbeta2+] 6/1


19 years ago
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?

Comment 18

19 years ago
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 
Component: User Interface: Design Feedback → Keyboard Navigation
QA Contact: mpt → sairuh

Comment 19

19 years ago
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]

Comment 20

19 years ago
I don't know of many laptop keyboards these days that don't have arrow keys.  
Number pads, sure.

Comment 21

19 years ago
ben fixed this a couple of days ago...
Last Resolved: 19 years ago19 years ago
Resolution: --- → FIXED

Comment 22

19 years ago
German is the Spec updated? if so, please enter the url here and update the 
status, thank you.
Keywords: verifyme

Comment 23

19 years ago
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.
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.)

Comment 25

19 years ago
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.
Last Resolved: 19 years ago19 years ago
Resolution: --- → FIXED

Comment 26

19 years ago
So really, this and bug 46803 are one and the same.  Anyone know if there's a 
bug filed on what Ben mentioned?

Comment 27

19 years ago
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

Comment 29

18 years ago
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.
Depends on: 47426
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.