Closed Bug 41325 Opened 24 years ago Closed 24 years ago

shortcuts for back/fwd don't work on Mac

Categories

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

PowerPC
Mac System 9.x
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: bugzilla, Assigned: saari)

References

Details

(Keywords: platform-parity, regression, Whiteboard: [nsbeta3+])

found this while verifying bug 29348; using opt comm bits on winnt,
2000.06.02.08. not a problem on linux or Mac.

1. surf to several webpages, to build up a history.
2. click Back button so that the Fwd button becomes active.
3. try to go back using Ctrl+[, or go fwd using Ctrl+].

result: nothing happens.
expected: should be able to go back and fwd, just as with the buttons.
Keywords: pp
Keywords: regression
over to keybd nav.
Component: XP Apps → Keyboard Navigation
Target Milestone: --- → M18
Hmm, why is this only a problem on Windows?
Similar command, ctrl-h for home, works on all platforms.
If I swap ']' and 'h' (switching home and forward),
then home stops working and forward works with 'h'.
Is something wrong with using ']' as an accelerator?
saari says toolkit bug, over to saari.
unmarking target milestone.
Assignee: mcafee → saari
Target Milestone: M18 → ---
there's another bug which points out the fact that we shouldn't be using '[' and ']' anyway.
We're supposed to be using the left and right arrows '<-' and '->'
I point this out so that we don't get caught up on the brackets themselves.
back and forward keyboard shortcuts should work for final ship
nsbeta3
Keywords: nsbeta3
nsbeta3+, commonly used feature.  Doesn't work for me on Win98 either.
Whiteboard: [nsbeta3+]
Status: NEW → ASSIGNED
Target Milestone: --- → M18
Isn't this fixed with ben's checkin? or still a problem?
Ctrl+[ seems to have been mapped to stop?!?
hmm..that's odd..you're right.  alt+left arrow and alt+right arrow still work
for back/fwd, and escape still works for stop, though.  can I close this up (and
I'll split off the ctrl+[ issue)?
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
erm, still doesn't work for me (using opt commercial bits 2000.08.15.08). does
this work for anyone else? btw, i just filed a bug that might be related: bug
49100 --also note that the shortcut labels are now Alt+[blank] on win32!
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
umm, my bad... Alt+Right Arrow and Alt+Left Arrow work as fwd and back. however,
i'm keeping this open since it's the Control key that's supposed to activate the
shortcut, not Alt. weird. could this be due to another bug, perhaps bug 47426?
Summary: shortcuts for back/fwd don't work on winNT → shortcuts for back/fwd don't work on winNT: should be ctrl, not alt
With today's builds:

win32
  alt+<-            causes browser to go back
  alt+->            causes browser to go forward
  alt+Home          causes browser to go home       *
  Backspace         causes browser to go back       **
  Shift-Backspace   causes browser to go forward    **                           
  
  F5                Reload                          **

linux 
  alt+<-            causes browser to go back
  alt+->            causes browser to go forward
  alt+Home          causes browser to go home       *
  alt+]             causes browser to go back       **
  alt+[             causes browser to go forward    **                           
   

mac 
  Cmd-[             Fails to go forward
  Cmd-]             Fails to go back 
  Cmd-Home          Fails to go home                *
 NOTE: Other Cmd-[A-Z] bindings works, e.g. Cmd-B, Cmd-S, Cmd-P.

*  defined in navigatorOverlay.xul as 'alt="true" keycode="VK_HOME"' 

** those are "double secret" keybindings, noted in the same platform-specific
   files where the Back and Forward keys are set. Just noting in passing.

So that is working per spec on win32 and linux, but not working for
Mac (bummer).  Bug still open for that reason (the Mac).

(sairuh, perhaps I'm confused, but the spec on Gooey says Alt+<- but makes
no platform distinction (e.g. Cmd for Mac at minimum). Not being Alt, though,
would break with the key strokes for Unix and Windows Navigator as far back 
as I recall. Is there somewhere I'm missing for information on what the spec 
is?)
Alt is supposed to be used for backwards-compatibility because that's the 
modifier 4.x used (it's also what IE uses).  There's a bug with that decision 
somewhere out there, but IE won't let me do Bugzilla queries (due to some 
content-disposition bugzilla bug)
Changing platform, OS, and summary to reflect Mac only status
OS: Windows NT → Mac System 9.0
Hardware: PC → Macintosh
Summary: shortcuts for back/fwd don't work on winNT: should be ctrl, not alt → shortcuts for back/fwd don't work on Mac: should be ctrl, not alt
If you do Alt(option) + home it works on MacOS. That isn't my problem, that is a
XUL bug.
This bug needs a new summary.  Macos doesn't have Alt. Consider resummarizing 
and changing OS/Platform. Thank you.
Erm Sorry. I wasn't paying attention.  Which means I need food and sleep.  Very 
Sorry.
The bug is that we call the OS routine ::ConvertTextToUnicode only for the 

Keypress event and that seems to mess up the key event. This routine 

seems to kill the "[" or "]" characters which are fine up until that conversion 

call, and are fine in the keydown and keyup events since we don't make 

that call in those code paths.



I don't understand the internationalization code nearly well enough to 

determine if this is a bug in our international code or in the OS, so I'm 

going to defer to more knowledgable people.



An obvious work around is to change the keybindings to keydown or keyup 

if the correct fix cannot be found.



Who should I assign this to?
reassigning to ftang
Assignee: saari → ftang
Status: REOPENED → NEW
accept
Status: NEW → ASSIGNED
It looks like currently the code in 
xpfe/browser/resources/content/mac/platformNavigationBindings.xul said the 
following:

Command + <- : Browser:Back
Command + -> : Browser:Forward
Command + . : BrowserStop()
Do you want me to add xul code so it will also do
Command + '[' : Browser:Back
Command + ']' : Browser:Forward 
???
I think we should at least change 
xpfe/browser/resources/content/mac/platformNavigationBindings.xul first.
We probably also need to fix widget code
for command + [ and command + ] on Mac. The following change along can fix it-
Index: platformNavigationBindings.xul
===================================================================
RCS file: /cvsroot/mozilla/xpfe/browser/resources/content/mac/
platformNavigationBindings.xul,v
retrieving revision 1.2
diff -c -2 -r1.2 platformNavigationBindings.xul
*** platformNavigationBindings.xul	2000/07/30 03:36:48	1.2
--- platformNavigationBindings.xul	2000/08/23 17:36:19
***************
*** 8,11 ****
--- 8,13 ----
      <key id="goBackKb" xulkey="true" keycode="VK_LEFT" observes="Browser:Back"/
>
      <key id="goForwardKb" xulkey="true" keycode="VK_RIGHT" observes=
"Browser:Forward"/>
+     <key id="goBackKbMac" xulkey="true" key="[" observes="Browser:Back"/>
+     <key id="goForwardKbMac" xulkey="true" key="]" observes="Browser:Forward"/>
      <key id="stopMac" xulkey="true" key="." onkeypres="BrowserStop();"/>
    </keyset>  

saari- can you do the code review ?
Whiteboard: [nsbeta3+] → [nsbeta3+]fix in hand for mac cmd+[ cmd+]
Blocks: 29941
check in the latest patch so cmd+[ and cmd+] do forward and backward on Mac. 
Reassign this bug to saari since contrl+<- and control+-> is broken on 
Window/Mac ...
reassign to saari
Assignee: ftang → saari
Status: ASSIGNED → NEW
Whiteboard: [nsbeta3+]fix in hand for mac cmd+[ cmd+] → [nsbeta3+]
I assume you meant Windows/Linux (you just fixed Mac to use [ and ]!), but they 
use alt+<- and alt+->.  And those work fine for me...

marking fixed (unless I'm missing something?)
Status: NEW → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
This bug's summary still needs to be changed. Since on mac it should show 
command not control.  I'm changing it.  If we are actually using control and 
not command then would someone please reopen?  I'm very sorry to mess with this 
bug.
Summary: shortcuts for back/fwd don't work on Mac: should be ctrl, not alt → shortcuts for back/fwd don't work on Mac: should be command, not alt
Build 2000082313, MacOS 9.0 ...
* Cmd+[: does nothing
* Cmd+]: does nothing
* Cmd+Left: goes back
* Cmd+Right: goes forward
* Ctrl+Left: does nothing
* Ctrl+Right: does nothing

So it looks like we have had an unsuccessful attempt to make one pair of
non-internationalization-safe shortcuts (Cmd+[ and Cmd+]) work, and the only 
shortcuts which do work (Cmd+Left and Cmd+Right) aren't internationalization-safe 
either -- because they're reserved by Mac OS for use with bidi keyboard layouts
<http://developer.apple.com/techpubs/mac/HIGuidelines/HIGuidelines-
213.html#HEADING213-16>.

I suggest:
* Don't try to implement Cmd+[ and Cmd+] -- back out ftang's code (which isn't
  working for some reason).
* Leave Cmd+Left and Cmd+Right as they are, as 4.x users (those who don't do
  bidi stuff) are used to them.
* Implement (and advertise in the menus) Ctrl+Left and Ctrl+Right, as an
  internationalization-safe (not to mention easier to type) pair of shortcuts.
  (Remember this applies only to Mac. Windows and X use Ctrl+Left/+Right to go
  between words in text fields, and Alt+Left/+Right to go Back/Forward.)

All of the above is shown in
<http://critique.net.nz/project/mozilla/general/interface/keys/>.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Summary: shortcuts for back/fwd don't work on Mac: should be command, not alt → shortcuts for back/fwd don't work on Mac
For me, on MacOS today Cmd+[ and Cmd+] work for me. Cmd+ -> and Cmd + <- do not.

fixed. Someone forget xulkey="false" in browserBindings.xul
Status: REOPENED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
vrfy fixed using 2000.09.05.04 on mac 9.0 [opt comm].
Status: RESOLVED → VERIFIED
fixing null OS field on old bugs
OS: Mac System 9.x
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.