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.

over to keybd nav.

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.

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

nsbeta3+, commonly used feature. Doesn't work for me on Win98 either.

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)?

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!

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?

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

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

accept

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 ?

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

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?)

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.

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/>.

For me, on MacOS today Cmd+[ and Cmd+] work for me. Cmd+ -> and Cmd + <- do not.

fixed. Someone forget xulkey="false" in browserBindings.xul

vrfy fixed using 2000.09.05.04 on mac 9.0 [opt comm].

fixing null OS field on old bugs