335693 - JavaScript "keypress" event listener stops receiving command key events for Cut, Copy, Paste

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, defect)

Description

[David Coletta]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.2) Gecko/20060308 Firefox/1.5.0.2
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.2) Gecko/20060308 Firefox/1.5.0.2

A JavaScript event listener for keypress events works correctly at first for command key events Cmd-X, Cmd-C, and Cmd-V. However, after a user picks "Copy" from the Edit menu, the handler no longer receives any keypress events for Cmd-C.

The problem does not go away after refreshing the page, but it does go away after closing and reopening the browser window.

Reproducible: Always

Steps to Reproduce:
1.  Load the attached HTML page.
2.  Select the letter "a" and press Command-C.
3.  Observe JavaScript alert window indicating that the event listener was called.
4.  Select the letter "a" and pick Copy from the Edit menu.
5.  Select the letter "a" and press Command-C.

Actual Results:  
No JavaScript alert window is displayed.

Expected Results:  
JavaScript alert window indicating that the event listener was called.

Note also that until the Copy command is picked from the Edit menu, the Edit menu does *not* flash when pressing Command-C, but after it is picked, it does flash.

Comment 1

[David Coletta]

Attachment: HTML file that reproduces bug 335693

Comment 2

[David Coletta]

This bug seems related to bug 256954, which has been closed as a dup of 220900.  I don't think this bug is a dup of 220900, though.  I think this bug is specifically OS X related.  And if that's true, then there's a good chance that 256954 is not actually a dup and should be reopened or duped to 335693.

Comment 3

[Stefan [:stefanh]]

This is probably related to some of our mac menu bugs. iirc once a menu have been opened it's the menu's shortcuts that takes over.

Comment 4

[Judson]

I don't know if this is related, but when I try and paste text into a javascript-called window (like making a link in wordpress using the easy link creator thing) command-p doesn't work anymore, I can right click, and select paste though.

Comment 5

[Josh Aas]

This is probably a dupe of bug 417108.

Comment 6

[Wes Campaigne]

Whatever the state of things were when this bug was reported have long since changed. The "listener stops receiving" aspect is no longer true: the page's js listener never receives cmd+c, ever, period.

Testing with the attached example shows that *no* cmd+letter keypresses are received by the listener -- regardless of whether something is bound to them or not. All key combos involving command + a non-printable key (F keys, arrows) DO generate events, unless they're mapped to some OS function. However, in these cases the keyCode value reported is "0", which obviously isn't right. (Values like "63234" are reported in Safari.)

That last bit holds in general: all non-printable except backspace and enter seem to report keyCode=0, regardless of modifiers. (The modifiers themselves seem to be reported correctly.)

Chords involving ctrl (including ones that are bound) are received.

On this test page, Safari does seem to pass the proper events down to the listener on the page in all cases except when the OS catches it (Exposé keys, for instance) and Safari itself doesn't receive the keypress.

How much of this functionality SHOULD there be?

Comment 7

[Josh Aas]

Sorry about my comment before, I didn't read the bug closely enough.

I have known about this bug for a long time, it is a limitation that our native menu architecture has. When a native menu item handles a command it eats the event after invoking the action. I have experimented with solving this in the past and we may be able to do it, but the change is really quite invasive and I wouldn't be comfortable taking it this late in the 1.9 cycle. We should make this a priority for Moz 2 though.

The patch called "menus only visually handle key events" on 398514 is part of my attempt at exploring a solution for this issue.

Comment 8

[Josh Aas]

Fixed by the final patch on bug 398514.