Closed Bug 17683 Opened 25 years ago Closed 25 years ago

[Dogfood] ALTGr + NUM Pad key operation shifts focus to menu

Categories

(MailNews Core :: Composition, defect, P3)

Product:
MailNews Core
Component:
Composition
Platform:
x86
Other
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: momoi, Assigned: joki)

Details

(Whiteboard: [PDT+] Fix expected by 11/22) 

** Observed with 11/1/99 Win32 build (1999110109) **

On US Windows, wwe can input Latin 1 accented charcters using Right ALT key + Number Pad (e.g.  0234).

To reproduce this bug:

1. Start composing on Plain text or HTML editor. The input field could either the Subject field or the Body Text.
2. Now insert the cursor into the Subject filed or Body Text area.
3. Input the following: ALTGr + 0234 (e with circumflex).
4. Note that the focus now has shifted to Menu area at the top of the window. If you now type "f", "e", "v", etc.,
   the menu will open because these are the shortcuts to these menus.

This makes it very difficult to input Latin 1 characters.
QA Contact: lchiang → momoi
Summary: ALT + NUM Pad key operation shifts focus to the menu → ALTGr + NUM Pad key operation shifts focus to the menu
Is this a QA blocker?
Status: NEW → ASSIGNED
Target Milestone: M11
Saari, any idea?
Summary: ALTGr + NUM Pad key operation shifts focus to the menu → [Dogfood] ALTGr + NUM Pad key operation shifts focus to the menu
We can input even with this problem. So in that sense not a blocker, but this is
something users of Latin 1 mail are going to notice and get annoyed by a lot.
For Latin1 input, I'm going to designate this as [Dogfood].
This bug is similar to bug 9333. It isn't a QA blocker but it is a major
annoyance. I'd vote for PDT+ myself.
Summary: [Dogfood] ALTGr + NUM Pad key operation shifts focus to the menu → [Dogfood] ALTGr + NUM Pad key operation shifts focus to menu
Confirmed for 1999-10-31-08-M11 nightly binary on Win95.

Additional Information:
1. This happens with both [ALT] keys. If memory serves, there is no
   [ALTGr] per se on the U.S. keyboard in MS-Windows - both are considered
   [ALT], and both can be used to enter Latin1 characters when NUMLOCK is
   on (even ascii characters).
2. As expected, this affects <TEXTAREA> and <INPUT> form controls also,
   and thus many form submissions for anyone with an accented name.
3. This problem happens even if focus is moved to another form control
   by clicking in that control between typing "ALT + 0234" and "f".
4. Note that typing "f" after "ALT + 0234" enters the "f" as well as dropping
   down the File menu - for some non-touch-typists, this will be doubly
   annoying, as there will be an expectation that the "f" was eaten by the
   menu (even if the menu shouldn't have appeared), and if the user immediately
   looks down to the keyboard again, it is easy to not notice and type the
   character a second time.
The bug that cpratt is mentioning prevents you from sending mail because in
many European keyboards, "@" sign can only be typed with ALTGr+ Num key
combinations.
Sorry, no num keys are needed, just AltGr+key...
Actually, the bug that cpratt mentioned has nothing to do with this one. Sorry!
Whiteboard: [PDT+]
Putting on PDT+ radar.
add saari to the list. Saari currently own the key binding code. He said that we probably still have some code which listen to KeyDown instead of
KeyPressed.
Speculation:
The cause of this bug and the cause of bug 17749 may have the same root:
somehow Mozilla does not notice that the ALT key is no longer being held down!
and treats a key pressed after ALT has been pressed and released as if
ALT+key had been typed. In bug 17749 ALT-TAB, released, or just ALT, released,
"sets up" the menu activation like the ALT+0234 does here.

Could it be as simple as that? If so, this is probably an event handling
problem.

Additional Information:
If, after entering ALT+0234 into a form control, any part of the page that
is *not* a form control is clicked on, then focus is returned to the
form control with another click, the menu activation does not happen
when an alpha key that is a menu hotkey is pressed.
JF, is this really your bug? If not, can you reassign to the right person.
Assignee: ducarroz → joki
Status: ASSIGNED → NEW
no, I don't think so it mime bug, it's look more like a event management problem. Reassign to joki
Target Milestone: M11 → M12
Many focus issues changing in m12, pushing out to there.
Status: NEW → ASSIGNED
Whiteboard: [PDT+] → [PDT+] Fix expected by 11/19
Saari's code is in, this should be easier to fix now
This bug seems much simpler than its summary suggests.
For the minimal case, type a character anywhere you can enter text, press
either ALT key, type another character while it is held down or not as you
please, release the ALT key, type "f", and watch the File menu drop down
as if the ALT key were still pressed down.
Whiteboard: [PDT+] Fix expected by 11/19 → [PDT+] Fix expected by 11/22
Fix should be in today.
Okay, alt+numpad entry should now just enter a character and not activate the
menu.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
** Checked with 12/6/99 Win32 build on NT4-US and Win98-J
   using the EN keyboard **

The problem mentioned in my original scenario, i.e. that of using
ALT + NUM Pad and triggering ALT key action, has been fixed.

The scenario "sidr@albedo.net" talks about in the
11/19/99 00:13 comment, I believe, is consistent with
how ALT key works. In this scneario, the menu selection
should be activated and selecting a matching access key
such as F should open the "File" menu if ALT + F are
pressed together. If the ALT key alone is pressed, then
then the focus should shift to the menu.
This is the bahevior observed in Communcator 4.x also and
I see no reason to change this behavior.

The original bug has been verified/fixed.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.