303713 - textbox.dispatchEvent(keyEvent) no longer adds character to textbox in Firefox 1.0.6

Status: RESOLVED FIXED

(Core :: DOM: Events, defect)

Description

[Orlin Todorov`]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6

The following javascript code which has been working for years stopped working
in FireFox 1.06:
	keycode=60;
	kE=kD.createEvent("KeyEvents");
	kE.initKeyEvent("keypress",1,1,null,0,0,0,0,keycode,keycode);
	el = document.getElementByID("input1");
	el.dispatchEvent(kE);

Reproducible: Always

Actual Results:  
The code above does not result in characters appearing in the 'input1' HTML. 
appears in the input text box.

Expected Results:  
The generated keystrokes should result in characters being typed in the input
text box.

This code has been working since Mozilla 1.0 (with the exception of one
regression in 2002).

Comment 1

[Bradley Baysinger]

I believe I have reproduced the same problem on this page:

http://bradleybaysinger.com/bugs/mozilla_dispatch_event.html

This is a doosy! 

Error: uncaught exception: [Exception... "Component returned failure code:
0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIDOMEventTarget.dispatchEvent]" 
nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame ::
http://bradleybaysinger.com/bugs/mozilla_dispatch_event.html :: redirect :: line
22"  data: no]

As you can see from the example element.dispatchEvent() doesn't work at all.
This has appeared on both the PC and Mac Platforms. Firefox 1.0.7 has apperently
inherited this bug from Firefox 1.0.6. I have not yet tested Firefox 1.5b.

Here is a link to some very cool code that is badly effected by this bug:

http://www.valleyfitness.com

Comment 2

[Bradley Baysinger]

This bug exists in Firefox 1.5 beta 1 AND Mozilla 1.7.12 on ALL platforms. This
is very unfortunate glitch. Firefox 1.5 beta 2 should NOT be released with this
bug!!

Comment 3

[Nickolay_Ponomarev]

Bradley: According to bz (see bug 194587 comment 8), "Redispatch of an event
that is currently being dispatch was disabled for security reasons."

I'm not sure though, if it is the same problem, as the original reporter's.   	
Orlin, could you confirm if it is, or attach a testcase demonstrating *your*
problem. Also, please tell us if it works in 1.5 beta.

Comment 4

[Orlin Todorov`]

(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10)
Gecko/20050716 Firefox/1.0.6
> Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10)
Gecko/20050716 Firefox/1.0.6
> 
> The following javascript code which has been working for years stopped working
> in FireFox 1.06:
> 	keycode=60;
> 	kE=kD.createEvent("KeyEvents");
> 	kE.initKeyEvent("keypress",1,1,null,0,0,0,0,keycode,keycode);
> 	el = document.getElementByID("input1");
> 	el.dispatchEvent(kE);
> 
> Reproducible: Always
> 
> Actual Results:  
> The code above does not result in characters appearing in the 'input1' HTML. 
> appears in the input text box.
> 
> Expected Results:  
> The generated keystrokes should result in characters being typed in the input
> text box.
> 
> This code has been working since Mozilla 1.0 (with the exception of one
> regression in 2002).

(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10)
Gecko/20050716 Firefox/1.0.6
> Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10)
Gecko/20050716 Firefox/1.0.6
> 
> The following javascript code which has been working for years stopped working
> in FireFox 1.06:
> 	keycode=60;
> 	kE=kD.createEvent("KeyEvents");
> 	kE.initKeyEvent("keypress",1,1,null,0,0,0,0,keycode,keycode);
> 	el = document.getElementByID("input1");
> 	el.dispatchEvent(kE);
> 
> Reproducible: Always
> 
> Actual Results:  
> The code above does not result in characters appearing in the 'input1' HTML. 
> appears in the input text box.
> 
> Expected Results:  
> The generated keystrokes should result in characters being typed in the input
> text box.
> 
> This code has been working since Mozilla 1.0 (with the exception of one
> regression in 2002).

(In reply to comment #3)
> Bradley: According to bz (see bug 194587 comment 8), "Redispatch of an event
> that is currently being dispatch was disabled for security reasons."
> 
> I'm not sure though, if it is the same problem, as the original reporter's.   	
> Orlin, could you confirm if it is, or attach a testcase demonstrating *your*
> problem. Also, please tell us if it works in 1.5 beta.

Hi Nikolay,
I checked the bug you mention and it is not the redispatch issue.  My code
creates and dispatches a new event.  I think it is the same problem that occured
 a couple of years back and was fixed then
(https://bugzilla.mozilla.org/show_bug.cgi?id=213144).  Here is a demo of the
problem: http://www.kredor.com/keyevent/keyevent.html.   
I am going to reopen the old bug.

Comment 5

[Nickolay_Ponomarev]

okay, I can confirm that this is broken in Mozilla/5.0 (Windows; U; Windows NT
5.1; en-US; rv:1.8b5) Gecko/20050925 Firefox/1.4, but working in 1.0.1.
According to Orlin, this has also regressed in Firefox 1.0.6

Comment 6

[Orlin Todorov`]

Hello everybody,

What is the situation with the bug?

I am getting emails from web sites about it.   I know of a couple of hundred web
sites that depend on this.

Please fix it before Firefox 1.5!  

Let me know if I can help with anything.

Thanks,
Orlin

Comment 7

[Scott MacGregor]

It's too late in the release cycle for this non stop ship bug which shipped in
1.0.6 as well.

Comment 8

[Asa Dotzler [:asa]]

Johnny, can you dig into this? Who else can help?

Comment 9

[Orlin Todorov`]

(In reply to comment #7)
> It's too late in the release cycle for this non stop ship bug which shipped in
> 1.0.6 as well.
> 

Hi Scott, this bug is really causing a lot of turmoil already and it will get a
lot worse if it ships in 1.5. It has been getting worse with every passing week
as more and more people upgrade to firefox 1.07 or 1.5 beta.
It was fixed a couple of years ago (see
https://bugzilla.mozilla.org/show_bug.cgi?id=213144).  Is the person who fixed
it not available anymore?

Comment 10

[Massimo Milan]

I'm building a javascript testing framework, loosely based on JSUnit. The possibility to simulate user input (mouse & keyboard) through synthetic Events is vital for such an application.
How would you then write automated testing for complex htlm/javascript widgets (autocompleted database query, to mention one)?

Comment 11

[Boris Zbarsky [:bzbarsky]]

This is probably a consequence of the trusted events change.  So there are two questions:

1)  Should textfields respond to untrusted events?  Maybe.  It's not clear to me whether they should, and we should probably sort that out.

2)  How does one make a DOM event trusted from privileged script.  I don't really see a way, and there should be one.

For what it's worth, I really don't see the "well, we shipped this breakage from a security fix in a security release too, so we should keep shipping it in this release" argument given in comment 7 as compelling....  I guess we're stuck for 1.8, but we should probably fix at least #2 above for 1.8.x...

Comment 12

[Jesse Ruderman]

> 1)  Should textfields respond to untrusted events?  Maybe.  It's not clear to
> me whether they should, and we should probably sort that out.

Should be safe enough, as long as autocomplete isn't triggered, you can't trigger commands (e.g. Ctrl+V for paste), and it doesn't work for (old-style) file upload controls.

Comment 13

[Boris Zbarsky [:bzbarsky]]

> you can't trigger commands (e.g. Ctrl+V for paste)

That could be pretty hard without some editor work, I suspect...

Comment 14

[[e-mail]]

(In reply to comment #13)
>>you can't trigger commands (e.g. Ctrl+V for paste)
>That could be pretty hard without some editor work, I suspect...
That's XBL, nothing to do with editor.

Comment 15

[[e-mail]]

Attachment: Proposed patch

Note: this patch has not been tested for security regressions.

Comment 16

[Orlin Todorov`]

Thanks Neil!

I hope this is the solution. 
  
I would like to mention again that this bug appeared once two and half years ago and was fixed then (see link in comment #9).  
Maybe we should insert a comment in the code to warn against future changes.

Orlin

Comment 17

[Boris Zbarsky [:bzbarsky]]

In which code, exactly?  This fix and the fix for bug 213144 are in totally different parts of the code.

Comment 18

[Orlin Todorov`]

Just a suggestion, I am not familiar with Mozilla development.  
Thanks.

Comment 19

[Johnny Stenback (:jst)]

Comment on attachment 203256 [details] [diff] [review]
Proposed patch

r+sr=jst

Comment 20

[[e-mail]]

Fix checked in to the trunk.

Comment 21

[Jesse Ruderman]

Gavin thinks this patch may have caused a trunk topcrash, bug 319732.

Comment 22

[Ryan Flint [:rflint] (ping via IRC for reviews)]

(In reply to comment #21)
> Gavin thinks this patch may have caused a trunk topcrash, bug 319732.
> 

Confirmed. Backing out this patch prevents bug 319732.

Comment 23

[Brian 'netdragon' Bober]

Now that this bug is in 1.5, we need a javascript workaround since this will show up for 1.5 users. Is there any method to trick 1.5 to allow, for example, to make http://bradleybaysinger.com/bugs/mozilla_dispatch_event.html work as intended? I'm trying to do setTimeout to a function and using createEvent to create a brand new event but unfortunately, I'm not having any luck getting this to work (unless I'm doing things wrong). Since Macromedia Flash with wmode=transparent still doesn't allow click-throughs in Firefox on a transparent region, I thought I could dispatch an event as a workaround to allow people to click what's underneath, but alas dispatching events was broken. That's why a workaround to get around this restriction would be very useful.

Comment 24

[Brian 'netdragon' Bober]

Attachment: Workaround

I created a workaround for those who are interested. It involves using createEvent instead of dispatching the existing event.

Comment 25

[Mike Schroepfer]

Comment on attachment 203256 [details] [diff] [review]
Proposed patch

Please consider for 1.8.1 - unless we have a roll-up patch and high confidence all regressions have been found and fixed.

Comment 26

[Brendan Eich [:brendan]]

On second thought, we would like to reconsider this bug, bug 319732, and any other bug regressed due to trusted events patch and related event dispatch fixes.  But we need a well-tested patch-set (or single patch for the branch, for all the bugs, if that's better for some reason).  Well-tested means baked for two weeks.

So renominate for 1.8.0.1 after more baking, and if possible construct a roll-up patch to consolidate review and approval.

/be

Comment 27

[[e-mail]]

Attachment: Rolled-up patch

Combines attachment 203256 [details] [diff] [review] with attachment 205433 [details] [diff] [review] and attachment 205611 [details] [diff] [review] from bug 319732 all of which were checked in to the trunk over a fortnight ago.

Comment 28

[[e-mail]]

Attachment: 1.7 branch version

Merge hell - This had better apply to the aviary branch too.

Comment 29

[Daniel Veditz [:dveditz]]

FIXED per comment 20

Comment 30

[Daniel Veditz [:dveditz]]

Comment on attachment 207317 [details] [diff] [review]
Rolled-up patch

Clearing approval request (not denying): Please get this rolled-up patch re-reviewed before seeking approval. Ditto especially for the "merge hell" 1.7 version, we don't want more regressions.

Comment 31

[[e-mail]]

Comment on attachment 203256 [details] [diff] [review]
Proposed patch

Seeing as the regression patches already have approval...

Comment 32

[Johnny Stenback (:jst)]

Comment on attachment 207321 [details] [diff] [review]
1.7 branch version

r+sr=jst

Comment 33

[Daniel Veditz [:dveditz]]

Comment on attachment 203256 [details] [diff] [review]
Proposed patch

a=dveditz for drivers

Comment 34

[Daniel Veditz [:dveditz]]

Comment on attachment 203256 [details] [diff] [review]
Proposed patch

didn't make 1.8.0.1 codefreeze, -> 1.8.0.2

Comment 35

[[e-mail]]

Fix checked into the branches.

Comment 36

[Ryan VanderMeulen [:RyanVM]]

Wasn't this RESOLVED FIXED a bit premature since comment #20 was referring to attachment 203256 [details] [diff] [review] being checked in, which was eventually backed out? And as best I can tell, attachment 207317 [details] [diff] [review] never made it onto the trunk.

I'm asking because in my most recent trunk build, the testcase still doesn't work properly (only the button 1 dialog comes up instead of both button 1 and button 2).

Moreso, I still get this in the Javascript Console:
Error: uncaught exception: [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIDOMEventTarget.dispatchEvent]"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: http://bradleybaysinger.com/bugs/mozilla_dispatch_event.html :: redirect :: line 21"  data: no]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060121 Firefox/1.6a1

Comment 37

[Boris Zbarsky [:bzbarsky]]

> which was eventually backed out?

It was?  There was a comment about testing via local backout, but nothing was backed out from mozilla.org CVS.

> And as best I can tell, attachment 207317 [details] [diff] [review] [edit] never made it onto the trunk.

How did you check?  According to LXR it did, at least the ELM part.

> the testcase still doesn't work properly

You mean the one in comment 1?  That should not work, in fact -- if it does we have a security hole.  That testcase is not what this bug was about.  All of which was covered in comment 3.

Comment 38

[Daniel Veditz [:dveditz]]

Comment on attachment 207321 [details] [diff] [review]
1.7 branch version

a=dveditz for drivers, please add fixed-aviary1.0.8 and fixed1.7.13 keywords when checked in.

Comment 39

[[e-mail]]

Fix checked into the aviary and 1.7 branches.

Comment 40

[Jay Patel [:jay]]

v.fixed on 1.0.1 Aviary branch with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060213 Firefox/1.0.8, key events appear in textbox using Orlin's demo/testcase http://www.kredor.com/keyevent/keyevent.html.

Comment 41

[Jesse Ruderman]

Bug 337975 wants to be able to use synthesized arrow keypresses in textareas as well as printing characters.