Closed Bug 20348 Opened 25 years ago Closed 25 years ago

[PP] Linux - Some Keyboard Shortcuts use Alt in Editor, Control in browser


(SeaMonkey :: UI Design, defect, P3)



(Not tracked)



(Reporter: elig, Assigned: akkzilla)



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

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

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


 - Occurs On
        Linux Apprunner (1999112908)

 - Doesn't Occur On
        Win32 Apprunner (1999112908 [NT 4, Service Pack 5])
        Mac OS Apprunner (1999112908)


- [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 Contact: don → elig
[qa assigning to self.]
Target Milestone: M12
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
Depends on: 14026
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.
Closed: 25 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.)

QA Contact: elig → sairuh
Menu bug --- QA Assigning to sarah for verification.
verified using 2000011308 comm bits for linux.
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.