Open Bug 308565 Opened 15 years ago Updated 7 months ago

`altKey` of `keypress` event is always false on macOS

Categories

(Core :: DOM: UI Events & Focus Handling, defect, P3)

PowerPC
macOS
defect

Tracking

()

ASSIGNED

People

(Reporter: adam.winer, Assigned: masayuki)

References

(Blocks 2 open bugs)

Details

(Keywords: parity-chrome, parity-safari)

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050721 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050721 Firefox/1.0+

In the following HTML snippet:

<input type="text" onkeypress="alert('alt? ' + event.altKey)">

... entering the field and hitting the "alt-A" keystroke (aka option-A) on the
Mac just shows "alt? false".  This correctly shows "alt? true" on Safari.  It
does work for onkeydown and onkeyup.

Reproducible: Always

Steps to Reproduce:
1. Add the following to a document:
 <input type="text" onkeypress="alert('alt? ' + event.altKey)">
2. Enter the field.
3. press option-a


Actual Results:  
You see "alt? false" in an alert.

Expected Results:  
You should have seen "alt? true in an alert.

MacOS 10.4.2
Repros in Firefox 1.0.3 and Deerpark alpha 2
Assignee: nobody → events
Component: General → DOM: Events
Product: Firefox → Core
QA Contact: general → ian
Version: unspecified → 1.8 Branch
see bug 300678 : that piece of JS code correctly determines the state of the
altkey (using onkeydown)
Mac widgetry issue.
Assignee: events → joshmoz
Component: DOM: Events → Widget: Mac
QA Contact: ian → mac
Depends on: 280805
it seems like one must use alt+(ctrl|cmd) to get a "true" value here.  for keycode 18 (alt) in about:config prefs. only the ctrl+alt variant works, though.

there must be some way to allow plain old (alt) as a modifier key...
this should probably get marked as a duplicate of bug 44259.
Why?  It doesn't seem very related to me...
(In reply to comment #5)
> Why?  It doesn't seem very related to me...
> 

yeah, maybe not.  i assumed that fixing bug 300678 would also take care of this one, and that was just marked as a dupe of 44259, ergo...
If it's not a dupe, then it's definitely a bug.  -->Cocoa
Status: UNCONFIRMED → NEW
Component: Widget: Mac → Widget: Cocoa
Ever confirmed: true
QA Contact: mac → cocoa
Version: 1.8 Branch → Trunk
Attached file test case
Assignee: joshmoz → nobody

Moving all keyboard/IME handling bugs to DOM: UI Events & Focus Handling component.

Component: Widget: Cocoa → DOM: UI Events & Focus Handling

Indeed, this could cause web-compat issue. I think that we can fix this bug with bug 1596916 because we need new flag in WidgetKeyboardEvent which indicate whether the eKeyPress event should introduce a character or not.

Depends on: 1596916
No longer depends on: 280805
Priority: -- → P3
Summary: event.altKey is always false for onkeypress on Mac → `altKey` of `keypress` event is always false on macOS
Assignee: nobody → masayuki
Status: NEW → ASSIGNED
No longer depends on: 1596916
See Also: → 1596916

The other browsers on macOS set altKey to true of keypress
events even when they introduce a chracter so that we should
follow same behavior for web-compat.

WidgetKeyboardEvent::IsInputtingText() has already ignore
MODIFIER_ALT flag only on macOS.
https://searchfox.org/mozilla-central/rev/4d9cd186767978a99dafe77eb536a9525980e118/widget/TextEvents.h#257-261
So, only IMEInputHandler stop the hack only for Alt state.

I think that we should put it off to change this our traditional behavior even though the new behavior is same as Blink/WebKit until COVID-19 calms down because we've experienced a lot of breakage with this kind of changes. What do you think?

Flags: needinfo?(htsai)
Flags: needinfo?(bugs)

Sounds reasonable.
In theory we could land the patch with a pref and enable the pref only on Nightly.

But this is a really old bug, so probably not hurry to land anything. Perhaps we want a meta bug to track which patches need to land later?

Flags: needinfo?(bugs)

(In reply to Olli Pettay [:smaug] from comment #13)

Sounds reasonable.
In theory we could land the patch with a pref and enable the pref only on Nightly.

But this is a really old bug, so probably not hurry to land anything. Perhaps we want a meta bug to track which patches need to land later?

Agreed to not hurry! Thank you for raising the concern, Masayuki.

Flags: needinfo?(htsai)

Thanks, filed bug 1625822 for tracking bugs like this.

You need to log in before you can comment on or make changes to this bug.