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)
Tracking
()
VERIFIED
FIXED
M18
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.
Updated•24 years ago
|
Keywords: regression
Updated•24 years ago
|
Target Milestone: --- → M18
Comment 2•24 years ago
|
||
Hmm, why is this only a problem on Windows? Similar command, ctrl-h for home, works on all platforms.
Comment 3•24 years ago
|
||
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 → ---
Comment 4•24 years ago
|
||
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.
Assignee | ||
Comment 5•24 years ago
|
||
back and forward keyboard shortcuts should work for final ship nsbeta3
Keywords: nsbeta3
Comment 6•24 years ago
|
||
nsbeta3+, commonly used feature. Doesn't work for me on Win98 either.
Whiteboard: [nsbeta3+]
Assignee | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → M18
Comment 7•24 years ago
|
||
Isn't this fixed with ben's checkin? or still a problem?
Assignee | ||
Comment 8•24 years ago
|
||
Ctrl+[ seems to have been mapped to stop?!?
Comment 9•24 years ago
|
||
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
Reporter | ||
Comment 10•24 years ago
|
||
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 → ---
Reporter | ||
Comment 11•24 years ago
|
||
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
Comment 12•24 years ago
|
||
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?)
Comment 13•24 years ago
|
||
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)
Assignee | ||
Comment 14•24 years ago
|
||
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
Assignee | ||
Comment 15•24 years ago
|
||
If you do Alt(option) + home it works on MacOS. That isn't my problem, that is a XUL bug.
Comment 16•24 years ago
|
||
This bug needs a new summary. Macos doesn't have Alt. Consider resummarizing and changing OS/Platform. Thank you.
Comment 17•24 years ago
|
||
Erm Sorry. I wasn't paying attention. Which means I need food and sleep. Very Sorry.
Assignee | ||
Comment 18•24 years ago
|
||
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?
Assignee | ||
Comment 19•24 years ago
|
||
reassigning to ftang
Assignee: saari → ftang
Status: REOPENED → NEW
Comment 21•24 years ago
|
||
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
Comment 22•24 years ago
|
||
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 ?
Updated•24 years ago
|
Whiteboard: [nsbeta3+] → [nsbeta3+]fix in hand for mac cmd+[ cmd+]
Comment 23•24 years ago
|
||
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 ...
Comment 24•24 years ago
|
||
reassign to saari
Assignee: ftang → saari
Status: ASSIGNED → NEW
Whiteboard: [nsbeta3+]fix in hand for mac cmd+[ cmd+] → [nsbeta3+]
Comment 25•24 years ago
|
||
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 ago → 24 years ago
Resolution: --- → FIXED
Comment 26•24 years ago
|
||
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
Comment 27•24 years ago
|
||
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
Assignee | ||
Comment 28•24 years ago
|
||
For me, on MacOS today Cmd+[ and Cmd+] work for me. Cmd+ -> and Cmd + <- do not.
Assignee | ||
Comment 29•24 years ago
|
||
fixed. Someone forget xulkey="false" in browserBindings.xul
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 30•24 years ago
|
||
vrfy fixed using 2000.09.05.04 on mac 9.0 [opt comm].
Status: RESOLVED → VERIFIED
Updated•5 years ago
|
Component: Keyboard: Navigation → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•