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

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect, P3)

Description

[Eli Goldberg]

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

Comment 1

[Eli Goldberg]

[qa assigning to self.]

Comment 2

[Akkana Peck]

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.

Comment 3

[Akkana Peck]

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.

Comment 4

[Akkana Peck]

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

Comment 5

[Eli Goldberg]

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?

Comment 6

[Akkana Peck]

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

Comment 7

[Eli Goldberg]

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!

Comment 8

[Eli Goldberg]

Menu bug --- QA Assigning to sarah for verification.

Comment 9

[sairuh (rarely reading bugmail)]

verified using 2000011308 comm bits for linux.