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

RESOLVED FIXED

Status

()

Core
DOM: Events
RESOLVED FIXED
12 years ago
6 years ago

People

(Reporter: Orlin Todorov`, Assigned: neil@parkwaycc.co.uk)

Tracking

(4 keywords)

1.8 Branch
x86
Windows XP
fixed1.7.13, fixed1.8.0.2, fixed1.8.1, regression
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.7.13 +
blocking-aviary1.0.8 +
blocking1.8rc1 -
blocking1.8.1 +
blocking1.8.0.1 -
blocking1.8.0.2 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [rft-dl])

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

12 years ago
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

12 years ago
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

12 years ago
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

12 years ago
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
(Reporter)

Comment 4

12 years ago
(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

12 years ago
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
(Reporter)

Comment 6

12 years ago
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

Updated

12 years ago
Flags: blocking1.8rc1?
Version: 1.7 Branch → 1.8 Branch

Comment 7

12 years ago
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-

Comment 8

12 years ago
Johnny, can you dig into this? Who else can help?
Assignee: events → jst
(Reporter)

Comment 9

12 years ago
(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

12 years ago
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

Comment 12

12 years ago
> 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...
(Assignee)

Comment 14

12 years ago
(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.
(Assignee)

Comment 15

12 years ago
Created attachment 203256 [details] [diff] [review]
Proposed patch

Note: this patch has not been tested for security regressions.
Attachment #203256 - Flags: superreview?(jst)
Attachment #203256 - Flags: review?(jst)
(Reporter)

Comment 16

12 years ago
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.
(Reporter)

Comment 18

12 years ago
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+
(Assignee)

Comment 20

12 years ago
Fix checked in to the trunk.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
(Assignee)

Updated

12 years ago
Attachment #203256 - Flags: approval1.8.0.1?
Attachment #203256 - Flags: approval1.7.13?
Attachment #203256 - Flags: approval-aviary1.0.8?
Depends on: 319732

Updated

12 years ago
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

Comment 21

12 years ago
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.
Created attachment 206018 [details]
Workaround

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

Comment 25

12 years ago
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
(Assignee)

Comment 27

12 years ago
Created attachment 207317 [details] [diff] [review]
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.
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 → ---
(Assignee)

Comment 28

12 years ago
Created attachment 207321 [details] [diff] [review]
1.7 branch version

Merge hell - This had better apply to the aviary branch too.
Attachment #207321 - Flags: approval1.7.13?
Attachment #207321 - Flags: approval-aviary1.0.8?
(Assignee)

Updated

12 years ago
Attachment #207317 - Flags: approval1.7.13?
Attachment #207317 - Flags: approval-aviary1.0.8?
FIXED per comment 20
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago12 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-
(Assignee)

Updated

12 years ago
Attachment #207321 - Flags: superreview?(jst)
Attachment #207321 - Flags: review?(jst)
(Assignee)

Comment 31

12 years ago
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+
(Assignee)

Comment 35

12 years ago
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.

Updated

12 years ago
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+
(Assignee)

Comment 39

12 years ago
Fix checked into the aviary and 1.7 branches.
Keywords: fixed-aviary1.0.8, fixed1.7.13

Comment 40

11 years ago
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.
Keywords: fixed-aviary1.0.8 → verified-aviary1.0.8

Updated

11 years ago
Whiteboard: [rft-dl]

Comment 41

11 years ago
Bug 337975 wants to be able to use synthesized arrow keypresses in textareas as well as printing characters.
Flags: blocking1.9a1?
Blocks: 698949
You need to log in before you can comment on or make changes to this bug.