Closed Bug 20348 Opened 24 years ago Closed 24 years ago
[PP] Linux - Some Keyboard Shortcuts use Alt in Editor, Control in browser
* TITLE/SUMMARY [PP] Linux - Keyboard Shortcuts use Alt in Editor, Control in browser <this has got to be a dupe, but I can't find it, and neither don or akkana know of one.> * STEPS TO REPRODUCE 0) Launch Apprunner 1) Click into a text field (e.g. the URL), and press "Control-A", and notice the text is selected. Deselect it, and try again using "Alt-A". Notice that it isn't selected. 2) From the Tasks menu, select "Composer" 3) Type some text into the window. Repeat step #1 using the Composer window as a text field. Note that the opposite occurs; "Control-A" will not select the text, but "Alt-A" will. * RESULT - What happened The keyboard shortcuts use different keys depending on whether you're in the browser or editor. Some shortcuts (e.g. New Window) will use accept both Control & Alt while in the Editor, but only Control while in the browser. - What was expected The same key should be used consistently. Melton says that the plan is to standardize on Alt, with Control as a pref exclusively on UNIX. (as other applications use it.) * REGRESSION - Occurs On Linux Apprunner (1999112908) - Doesn't Occur On Win32 Apprunner (1999112908 [NT 4, Service Pack 5]) Mac OS Apprunner (1999112908) * CONFIGURATIONS TESTED - [Mac] Beige Power Mac G3 (266 MHz PowerPC 750), 96 MB RAM (VM on; 1 MB of VM used), 1024x768 (Thousands of Colors), Mac OS 8.6 - [Win32] Vectra VL (233 MHz P2), 96 MB RAM, 800x600 (True Color), NT 4.0 SP5. - [Linux] Vectra VL (266 MHz P2), 96 MB RAM. Red Hat Linux 6.0 (GNOME).
[qa assigning to self.]
I'll investigate. I doubt it's a dup, since the Unix alt shortcuts just got turned on a couple of days ago, and hardly anyone tests keyboard bindings anyway.
The reason you're seeing this is that the browser window isn't using the XUL bindings because it has no way to get the currently focused element (related to bug 14026), and the default editor key bindings (compiled in in nsEditorEventListeners, for the case where XUL may not be present) are hardwired to use control. I'll change the compiled-in editor listeners to use alt for Unix (it already has ifdef'ed code for Mac, I suppose adding another platform isn't any worse ... sigh) but the real fix is to get 14026 fixed, so that the browser window will use the default XUL keybindings and route them to the appropriate widget.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
I've checked in a fix to make alt the default compiled-in modifier for Unix. (This also touched the Windows and Mac code, so it's probably good to test those platforms as well.)
Confirmed no obvious breakage on Mac OS & Win32 menu items in Browser & Editor using 1999121008 build. Overall, it looks okay, we now have quite a few menu conflicts because we use Alt both to access menus (e.g. Alt-H for Help menu), and for direct menu item access (e.g. Alt-H for "Home", within the Browser.) akkana? don?
I'm not actually sure what the menu access key is on linux, but I don't think it's alt. (Isn't it F1 or F12 or something on Solaris?) (A quick poll in the X pit and on IRC turned up no one who knew; if I find anyone who knows, I'll add another comment.)
Hey, hyatt --- Akkana indicated you'd know what bug # covers Alt not being the correct linux menu access key. What bug # might that be? (just want to confirm that one exists.) Thanks!
Menu bug --- QA Assigning to sarah for verification.
verified using 2000011308 comm bits for linux.
You need to log in before you can comment on or make changes to this bug.