Closed Bug 160556 Opened 23 years ago Closed 22 years ago

Navigation Shortcuts have been re-broken.

Categories

(Camino Graveyard :: Accessibility, defect)

Product:
Camino Graveyard
Component:
Accessibility
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: alanbrent, Assigned: sfraser_bugs)

References

Details

The navigation shortcuts for forward/backward and tabright/tab-left have been b0rked yet again, hopefully by mistake. This happened I believe in the 07292002 nightly. I remember this being a pretty hot issue in the past and that (shift)cmd+left and (shift)cmd+right were already decided on.
Using Chimera/20020801, Command+[ and Command+] are back and forward. This is probably as it should be, to match Mozilla if nothing else. I think it was determined that using the arrow keys was a bad idea, as Apple's HIGs says they're to be used for a lot of text field navigation.
i realize that those are the "new" shortcuts, but i was also under the impression that this debate was long overwith and that the arrow keys were settled upon. the [ and ] keys are fine for us US keyboard users, but can be an immense pain for others in the world. Although the [ and ] keys function the same way in mozilla, so do the arrow keys. Let's have a decision, or stick with the one already made.
Brent, you may have to wait for localized versions of Chimera to have different shortcuts, presumably whatever Mozilla uses in the corresponding localization.
cc: sfraser, I believe you changed the keyboard navigation shortcuts from cmd-left-arrow/cmd-right-arrow to cmd-[/cmd-]?
I suggest we WONTFIX this, unless someone can come up with a better plan. Other browsers use Command-[], for the same reason that we have to: Command-arrows are reserved for navigation in text.
thats fine that other browsers use this shortcut, but i have yet to run in to one that doesn't ALSO accept the cmd-arrows shortcuts as well.
While it may be true that cmd-arrows are reserved for text editing I should like to have the actual key assignment customizable (also to cmd-arrows if desired) because cmd-[/] are a bit awkward on a Danish (and probably other non-US keyboards). Btw Mozilla 1.1b uses cmd-arrows and not cmd-[/], on a Danish keyboard at least.
You can use NSUserDefaults to modify the key shortcuts of any application, e.g. <http://mozdev.org/pipermail/chimera/2002-June/002274.html>
"you may have to wait for localized versions of Chimera to have different shortcuts, presumably whatever Mozilla uses in the corresponding localization." so you mean to say that the developers would much rather have MORE work to do later, or even contract it out to other people to do a localization, when the left and right keys are perfectly acceptable on a vast majority of keyboard layouts???? this is a widely accepted shortcut that has no real problems as far as functionality go. the [ and ] keys are a nightmare even for US keyboard users. To WONTFIX this bug without a real explanation as to WHY the [ ] keys are being used, from a USABILITY standpoint, would be quite unwise. Don't let your corporate backgroundstaint you here. Just because your bosses suck doesnt mean your software has to. And it really doesnt. This is just one of those things that is quite indicative in MY OPINION (<---) of a misdirection on the parts of the engineers. [ and ] is not more "maclike", its just plain counterintuitive. Wheres Blake when you need him??
> this is a widely accepted shortcut So are Command-arrows for text navigation.
Component: General → Accessibility
QA Contact: winnie → sairuh
Back navigation keyboard navigation is broken (menu: Go->Back), at least on a Danish keyboard (opt-cmd-[). Forward navigation is not. Build: 20002082705
*** Bug 167411 has been marked as a duplicate of this bug. ***
Mine
Assignee: saari → sfraser
*** Bug 161009 has been marked as a duplicate of this bug. ***
To reiterate what I said in 161009, and hopefully be alittle more concise. Allow me to distinguish between editing text and browsing, which are the conflicting modes that seem to cause this debate. There is already an analogue to this with respect to the mappings for PageUp and PageDown. If you are editing they operate within the edit context (i.e. the text box, or what have you); if you are browsing they operate within the browsing context (i.e. the whole window). To me this is the correct behaviour. Given that is correct, then to me it also seems correct to adopt the same behaviour onto the Cmd-Arrow keys. So to me, the correct behaviour should be as follows: #define editing = focused on an text edit box if( editing ) Cmd-Arrows are mapped to textbox functionality per Apple HIG else Cmd-Arrows are mapped to Back/Forward The Apple HI guidelines may specify what the command-arrow keys should do when editing text, but that does not exlude other mappings in a mixed-mode environment, according to my reading. As far as user confusion is concerned, there's always that possibility when modes are involved. Certainly it is a goal to avoid modes and mode-related problems as much as possible. However in this case, the HIG clearly defines CmdArrows in edit mode, and users are clearly accustomed to CmdArrows in browser mode. Two options presented in this bug seem to be either choose to re-educate the users (disable CmdArrows in browse mode) or to find a compromise that allows both mappings to exist. Obviously I think that compromising is best. Some means of detecting user confusion could be devised, but I think i've said enough for now...
I guess I'm all for following the human interface guidelines, and I guess my comments won't really change anyone's mind. But, every other major browser on the platform does this "wrong" wrt. the arrow keys (except the help viewer). I think following de facto standards is more important than some theoretical guideline. I'd be using chimera instead of mozilla if this were fixed.
It is quite irritating to have to remember a different keystroke combination when moving from one browser/platform to Chimera. I'm not sure what the resistance is to this when almost all of the written commentary I've seen is in favor of the Cmd -> and Cmd <- key combination, international and US.
*** Bug 167840 has been marked as a duplicate of this bug. ***
Fix checked in. Command-arrow keys now go Forward and Back, when gecko doesn't want the key (and the url bar is not focussed).
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
vrfy'd fixed, 2002.09.20.04. cmd-[ / ] still go back and fwd, whether or not focus is in a textarea. cmd-left/right arrows also do the same --except when focus is in a textarea, as expected.
Status: RESOLVED → VERIFIED
*** Bug 171614 has been marked as a duplicate of this bug. ***
*** Bug 172915 has been marked as a duplicate of this bug. ***
*** Bug 177098 has been marked as a duplicate of this bug. ***
*** Bug 172915 has been marked as a duplicate of this bug. ***
Could someone please reopen this bug? Current trunk buils do again no longer support CMD-LEFT and CMD-RIGHT to navigate Back and Forward.
We don't re-open five-year-old bugs that happen to have the same symptoms as a new issue; please file a new bug.
At least he actually searched the bug base!
(In reply to comment #27) > please file a new bug. OK, I opened Bug 379199.
You need to log in before you can comment on or make changes to this bug.