Closed Bug 303713 Opened 15 years ago Closed 15 years ago

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

Categories

(Core :: DOM: Events, defect)

1.8 Branch
x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: orlink, Assigned: neil)

References

Details

(4 keywords, Whiteboard: [rft-dl])

Attachments

(3 files, 1 obsolete file)

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).
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
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!!
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.
Assignee: nobody → events
Component: General → DOM: Events
Product: Firefox → Core
QA Contact: general → ian
Version: unspecified → 1.7 Branch
(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.
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
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
Flags: blocking1.8rc1?
Version: 1.7 Branch → 1.8 Branch
It's too late in the release cycle for this non stop ship bug which shipped in
1.0.6 as well.
Flags: blocking1.8rc1? → blocking1.8rc1-
Johnny, can you dig into this? Who else can help?
Assignee: events → jst
(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?
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)?

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...
Flags: blocking1.9a1?
Flags: blocking1.8.1?
Blocks: 289940
> 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.
> you can't trigger commands (e.g. Ctrl+V for paste)

That could be pretty hard without some editor work, I suspect...
(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.
Attached patch Proposed patch (obsolete) — Splinter Review
Note: this patch has not been tested for security regressions.
Attachment #203256 - Flags: superreview?(jst)
Attachment #203256 - Flags: review?(jst)
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




In which code, exactly?  This fix and the fix for bug 213144 are in totally different parts of the code.
Just a suggestion, I am not familiar with Mozilla development.  
Thanks.
Comment on attachment 203256 [details] [diff] [review]
Proposed patch

r+sr=jst
Attachment #203256 - Flags: superreview?(jst)
Attachment #203256 - Flags: superreview+
Attachment #203256 - Flags: review?(jst)
Attachment #203256 - Flags: review+
Fix checked in to the trunk.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Attachment #203256 - Flags: approval1.8.0.1?
Attachment #203256 - Flags: approval1.7.13?
Attachment #203256 - Flags: approval-aviary1.0.8?
Depends on: 319732
Summary: element.dispatchEvent(event) for a key event stopped working in FireFox 1.06 → textbox.dispatchEvent(keyEvent) no longer adds character to textbox in Firefox 1.0.6
Gavin thinks this patch may have caused a trunk topcrash, bug 319732.
(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.
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.
Attached file Workaround
I created a workaround for those who are interested. It involves using createEvent instead of dispatching the existing event.
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.
Attachment #203256 - Flags: approval1.8.0.1? → approval1.8.0.1-
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
Attached patch Rolled-up patchSplinter Review
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.
Assignee: jst → neil.parkwaycc.co.uk
Attachment #203256 - Attachment is obsolete: true
Status: RESOLVED → ASSIGNED
Attachment #207317 - Flags: approval1.8.1?
Attachment #207317 - Flags: approval1.8.0.1?
Attachment #207317 - Flags: approval1.7.13?
Attachment #207317 - Flags: approval-aviary1.0.8?
Attachment #203256 - Flags: approval1.7.13?
Attachment #203256 - Flags: approval-aviary1.0.8?
Resolution: FIXED → ---
Merge hell - This had better apply to the aviary branch too.
Attachment #207321 - Flags: approval1.7.13?
Attachment #207321 - Flags: approval-aviary1.0.8?
Attachment #207317 - Flags: approval1.7.13?
Attachment #207317 - Flags: approval-aviary1.0.8?
FIXED per comment 20
Status: ASSIGNED → RESOLVED
Closed: 15 years ago15 years ago
Resolution: --- → FIXED
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.
Attachment #207317 - Flags: approval1.8.1?
Attachment #207317 - Flags: approval1.8.0.1?
Flags: blocking1.8.0.1?
Flags: blocking1.8.0.2?
Flags: blocking1.8.0.1?
Flags: blocking1.8.0.1-
Attachment #207321 - Flags: superreview?(jst)
Attachment #207321 - Flags: review?(jst)
Comment on attachment 203256 [details] [diff] [review]
Proposed patch

Seeing as the regression patches already have approval...
Attachment #203256 - Flags: approval1.8.1?
Attachment #203256 - Flags: approval1.8.0.1?
Attachment #203256 - Flags: approval1.8.0.1-
Comment on attachment 207321 [details] [diff] [review]
1.7 branch version

r+sr=jst
Attachment #207321 - Flags: superreview?(jst)
Attachment #207321 - Flags: superreview+
Attachment #207321 - Flags: review?(jst)
Attachment #207321 - Flags: review+
Comment on attachment 203256 [details] [diff] [review]
Proposed patch

a=dveditz for drivers
Attachment #203256 - Flags: approval1.8.1?
Attachment #203256 - Flags: approval1.8.1+
Attachment #203256 - Flags: approval1.8.0.1?
Attachment #203256 - Flags: approval1.8.0.1+
Comment on attachment 203256 [details] [diff] [review]
Proposed patch

didn't make 1.8.0.1 codefreeze, -> 1.8.0.2
Attachment #203256 - Flags: approval1.8.0.2+
Attachment #203256 - Flags: approval1.8.0.1-
Attachment #203256 - Flags: approval1.8.0.1+
Fix checked into the branches.
Keywords: fixed1.8.1
Whiteboard: fixed1.8.0.2
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
> 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.
Keywords: fixed1.8.0.2
Whiteboard: fixed1.8.0.2
Flags: blocking1.8.1?
Flags: blocking1.8.1+
Flags: blocking1.8.0.2?
Flags: blocking1.8.0.2+
Flags: blocking1.7.13+
Flags: blocking-aviary1.0.8+
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.
Attachment #207321 - Flags: approval1.7.13?
Attachment #207321 - Flags: approval1.7.13+
Attachment #207321 - Flags: approval-aviary1.0.8?
Attachment #207321 - Flags: approval-aviary1.0.8+
Fix checked into the aviary and 1.7 branches.
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.
Whiteboard: [rft-dl]
Bug 337975 wants to be able to use synthesized arrow keypresses in textareas as well as printing characters.
Flags: blocking1.9a1?
You need to log in before you can comment on or make changes to this bug.