213144 - dispatchEvent for a key event stopped working since Mozilla 1.4

Status: RESOLVED FIXED

(Core :: DOM: Events, defect)

Description

[Orlin Todorov`]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624

This code used to work with Mozilla 1.0, 1.1, 1.2, and I think under 1.3a.  It 
is not working anymore.
The event seems to get initialized properly, but after dispatchEvent nothing 
appears.  
var k=1050; // key code
e=document.createEvent("KeyEvents");
e.initKeyEvent("keypress",1,1,null,0,0,0,0,k,k);
elmnt.dispatchEvent(e);



Reproducible: Always

Steps to Reproduce:
1. Create a simple web page with a text box
2. Add a function to generate a keypress event like the code above
3. Call the function with setTimeout for example.

Actual Results:  
No character appears in the text box

Expected Results:  
A character should appear in the textbox.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Does it work if you also send keydown and keyup events?  Could you attach a
testcase?

It's not inconceivable that this is a security fix....

Comment 2

[Orlin Todorov`]

I am not sure about keyup and keydown.   The strange thing is that an event 
listener catches the dispatched event, but nothing appears. 
Here is a test page:
http://www.kredor.com/keyevent/keyevent.html
Clicking on the button 'Keypress' should put a character into the text field, 
but nothing appears.  The event listener attached to the text field catches 
the event though and its keyCode and charCode values are correct.

Thank you very much for the assistance.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Yeah, this this definitely feels like a security fix.

Comment 4

[Orlin Todorov`]

Hi Boris,

Can you explain why it seems to be a security fix?  Can it be restored to the 
way it was?  How?  How can I find out what the cause is for sure?
If I can set the value of a field via javascript why would sending keystrokes 
to it be a problem?
If it is a security fix, maybe the fix should be blocking non-printable 
characters only.  

Comment 5

[Boris Zbarsky [:bzbarsky]]

I'm just basing that comment on remembering some vulnerabilities associated with
key events (eg key events bubbling up to the browser toolbar, etc).  It _may_ be
that one of those fixes changed the behavior here.

Comment 6

[Orlin Todorov`]

Hi Boris,

Are you familiar with mozilla processes?  What can I do to get this bug fixed?

Thanks.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Well, the first step is to find out what changed... 

It looks like the behavior changed between the 2003-03-23-05 build and
2003-03-25-05 build.  The checkin that looks most suspicious in that period is
the one for bug 54035.

bryner, do events created via the DOM get dispatched to the system group?

Comment 8

[Orlin Todorov`]

Wow, thank you Boris!

That's significant progress!  I hope Brian can shed light on this.

Comment 9

[chris hofmann]

getting assignment straighened out.  cc jst.  maybe byner, jst, or callion can
make some progress on this for 1.7

Comment 10

[alexander :surkov (:asurkov)]

I think http://bugzilla.mozilla.org/show_bug.cgi?id=178134 is dublicate of this bug.

Comment 11

[Michael O.]

Just wanted to comment that this bug is blocking development of a keymapping
extension that would allow users to easily define new key combinations for
browser commands.

In the SuperScroll extension for Mozilla Firebird, which allows for vi-style
directional scrolling that does not interfere with the Find As You Type search
feature, I am forced to emulate key commands (scroll / PageUp / PageDown / Home
/ End) instead of being able to simply create a new keypress event that can be
handled by the browser core or another event listener.

Comment 12

[chris hofmann]

byner has a patch coming

Comment 13

[Brian Ryner (not reading)]

Attachment: patch

This patch sends synthetic events through the system event group the same way
as user events, by mirroring the logic in PresShell::HandleEventInternal(). 
This would have regressed when editor was changed to use the system event group
for typing characters.

(It would be nice to have this code shared between ESM and PresShell... I'd
like to centralize event dispatch sometime which would make that sharing easy
to do).

Comment 14

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 141475 [details] [diff] [review]
patch

r+sr=bzbarsky.	And yes, centralizing event dispatch would be great....
especially if it makes possible dispatch of events in documents with no
presshell (eg mutation events).

Comment 15

[chris hofmann]

Comment on attachment 141475 [details] [diff] [review]
patch

a=chofmann for 1.7a

Comment 16

[Brian Ryner (not reading)]

checked in.

Comment 17

[Orlin Todorov`]

(In reply to comment #16)
> checked in.

Great Job!  Thanks!

Comment 18

[Serge Gautherie (:sgautherie)]

(In reply to comment #2)
> Here is a test page:
> http://www.kredor.com/keyevent/keyevent.html

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a1) Gecko/20040520] (release) (W98SE)

This works :-)

But, for the record,
{{
e.keyCode=90;
}}
generates
{{
Error: setting a property that has only a getter
Source File: http://www.kredor.com/keyevent/keyevent.html
Line: 17
}}

Comment 19

[Orlin Todorov`]

(In reply to comment #17)
> (In reply to comment #16)
> > checked in.
> 
> Great Job!  Thanks!

The bug reappeared in Firefox 1.06!  It behaves exactly the same as the previous
time two years ago.  See the demo page in the second comment.

Thank you!
Orlin

Comment 20

[Nickolay_Ponomarev]

The bug on regression is bug 303713.