Closed Bug 276846 Opened 20 years ago Closed 18 years ago

input event fired with a dispatchEvent isn't caught by eventListener

Categories

(Core :: DOM: Events, defect)

Product:
Core
Component:
DOM: Events
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: robert.strong.bugs, Unassigned)

References

Details

(Keywords: testcase, Whiteboard: Ignore comment 14 to comment 20)

Attachments

(5 files, 2 obsolete files)

testcase (XUL)
2.86 KB, application/vnd.mozilla.xul+xml
Details
testcase (HTML)
2.52 KB, text/html
Details
Assert triggered by that testcase
1.47 KB, patch
Details | Diff | Splinter Review
Eventlisteners fails on events dispatched by dispatchEvent II
2.31 KB, text/html
Details
testcase using "UIEvents"
2.52 KB, text/html
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

When using dispatchEvent to fire an input event the event is never caught by an
eventListener on the element. I haven't been able to find specs for this so it
is quite possibly invalid. Testcase soon to be attached.

Reproducible: Always

Steps to Reproduce:
1. open soon to be attached testcase
2. follow instructions on testcase
3.

Actual Results:  
input event is not caught by the eventListener

Expected Results:  
input event is caught by the eventListener if indeed it should be
Confirmed; HTML testcase looks right to me. How weird.
The reason this is happening is that "input" is not in the list in
nsDOMEvent::SetEventType.

I can fix that, but it'd not be treated correctly anyway, since "input" events
are nsGUIEvent, not nsEvent (so creating an "input" event by
createEvent("Events") doesn't work right).  Unfortunately,
createEvent("GUIEvents") also does not work (createEvent doesn't handle that).

So questions:

1)  What event module should "input" live in?
2)  What should the event struct type be for the nsEvent it creates?
    NS_GUI_EVENT?
3)  What is the exact relationship between all this stuff?  eg the "submit"
    event is an nsFormEvent when dispatched internally, but an nsEvent when
    created via createEvent().  That seems wrong...
Note that that assert will also fire if people create an event in the wrong
module, so I don't think we actually want to check it in...
We should fix it; it's not a huge amount of work once my questions in comment 4
are answered.  bryner, jst, any chance you might be able to answer those?
Flags: blocking1.8b3?
Per DOM, as I understand it, you should be able to create an element of any name
(including unknown names) implementing any of the interfaces that inherit from
Event (directly or indirectly). Not sure you wanted to hear that, though.
Ian, I don't think anyone's arguing that the event creation/dispatch system in
general is a mess.  We have bugs to fix it up some.  But not for 1.8, whereas
this bug could be fixed for 1.8.
My comment was not in any way intended to suggest a timescale for fixing this
bug, either completely or in part. I just meant to point out what the specs
currently say we should be ultimately aiming for. :-)
Attached file Test case (XUL) - window event (obsolete) — 
I'd like to figure out why the window XULElement can catch custom event and not
the other XULElement.

This test case shows that when a custom "foo" event is attached to the window
XULElement, this element can catch the dispatchEvent("foo") and that the other
XULElement just ignore the dispatchEvent.
That has nothing to do with this bug, and you're only seeing a problem because
your code is wrong.  If you have a XUL or DOM authoring question, please ask it
in the relevant newsgroup instead of spamming unrelated bugs.
Life sucks and patches would be great, but we're not going to block on this.
Flags: blocking1.8b3? → blocking1.8b3-
I'd love to post a patch if someone familiar with our event impl would just
answer my questions from comment 4.
Attachment #186571 - Attachment is obsolete: true
(In reply to comment #8)
> Ian, I don't think anyone's arguing that the event creation/dispatch system in
> general is a mess.  We have bugs to fix it up some.  But not for 1.8, whereas
> this bug could be fixed for 1.8.

Seems to be more than comment #4 that needs to be answered in this case :)

As you can se in my attachment there also seems to be a general problem in the dispatchEvent system. The eventListener system seems to do the job when events are dispatched by the browser but fails when dispatced by dispatchEvent
Comment on attachment 222717 [details]
Eventlisteners fails on events dispatched by dispatchEvent

><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Strict//EN">
><HTML><HEAD><TITLE>DispatchEvent bug?</TITLE>
>
>
>
>	
><SCRIPT src="debug.js" language="JavaScript1.2" type="text/javascript"/></HEAD><BODY onload="init()">
><TABLE width="90%" border="1" bgcolor="#e0fadc" id="table_1">
> <TBODY>
>  <TR>
>   <TD>
><H4>id = 'table_1'</H4>
>This table is connected to Eventlistener click(), set by body 'onload=init()'
><PRE>function init()
>{
>	var t1 = document.getElementById('table_1');
>	if (t1.addEventListener)	{  t1.addEventListener('click', click, null);  }
>	else				{  t1.attachEvent('click', click, false);	}
>}
>function click()
>{
>	alert('In click()');
>}
></PRE>
>Click on this table to trigger function click() 
><BR/><BR/>
>   </TD>
>  </TR>
> </TBODY>
></TABLE>
><TABLE width="90%" border="1" bgcolor="#e0fadc" id="table_2">
> <TBODY>
>  <TR>
>   <TD>
>    <H4>id = 'table_2'</H4>
>The 'Dispatch'-button runs function execute() which dispatches a 'click'-event to 'table_1'<BR/>
>This should cause the same responce as clicking on 'table_1' but nothing happends<BR/>
><BR/>
>    <INPUT type="button" id="dispatch_btn" onclick="execute()" value="Dispatch click-event to 'table_1'"/>
><PRE>function execute()
>{
>	var ev = document.createEvent('HTMLEvents');
>	var type = 'click';
>	var bubble = 0;
>	var capture = 0;
>	var target_id = 'table_1';
>
>	ev.initEvent(type, bubble, capture);
>	var target = document.getElementById(target_id);
>	var res = target.dispatchEvent(ev);
>	alert('dispatchEvent \'' + type + '\' to \'' + target_id + '\' done, bubble = ' + bubble + ', capture = ' + capture + '\n\nresult: ' + res);
>}
></PRE>
>   </TD>
>  </TR>
> </TBODY>
></TABLE>
>
><SCRIPT type="text/javascript" language="javascript1.2">
>function init()
>{
>	var t1 = document.getElementById('table_1');
>	if (t1.addEventListener)
>	{
>		t1.addEventListener('click', click, null);
>	}
>	else
>	{
>		t1.attachEvent('click', click, false);
>	}
>}
>function click()
>{
>	alert('In click()');
>}
>function execute()
>{
>	var ev = document.createEvent('HTMLEvents');
>	var type = 'click';
>	var bubble = 0;
>	var capture = 0;
>	var target_id = 'table_1';
>
>	ev.initEvent(type, bubble, capture);
>	var target = document.getElementById(target_id);
>	var res = target.dispatchEvent(ev);
>	alert('dispatchEvent \'' + type + '\' to \'' + target_id + '\' done, bubble = ' + bubble + ', capture = ' + capture + '\n\nresult: ' + res);
>}
>
></SCRIPT>
></BODY></HTML>
Comment on attachment 222717 [details]
Eventlisteners fails on events dispatched by dispatchEvent

>	alert('dispatchEvent \'' + type + '\' to \'' + target_id + '\' done, bubble = ' + bubble .....

Typo in attachments displayed code: target_i, not id
(In reply to comment #15)
Sorry for comment #15, was not what I intended (may be deleted)
You're creating an event of the wrong type (HTMLEvents, not MouseEvents), so no wonder that it doesn't work.  Further, none of your comments had anything to do with this bug, and you've just made it a _lot_ more difficult to read this bug, due to comment 15.  Please be more careful in the future.
Flags: blocking1.9a1?
(In reply to comment #18)
> You're creating an event of the wrong type (HTMLEvents, not MouseEvents), so no
> wonder that it doesn't work.  
Sorry for that - was originaly trying to get the resize-event to work but had no success and changed to the click-event without changing the event-type
(.. causing wrong conclusion)

The problem is that I'm trying to react on the resize-event when a table is resized due to change in content or window-size. It seems that no resize event is fired against the table so I need to dispatch that event from the window onresize event. 

My point is to confirm that It seems to be the event-listener that is the problem and not only for the input-event :)

(originaly posted in bug 227495 - Opened: 2003-12-04 11:06 PDT)
Attachment #222717 - Attachment is obsolete: true
Yes, that's showing the same problem as this bug (see comment 4).  Now we've doubled the size of the bug for no benefit.
Whiteboard: Ignore comment 14 to comment 20
Flags: blocking1.9a1? → blocking1.9-
Smaug, see comment 4.  I'd love feedback.
Since "wrong" event is created, it should be marked NS_USER_DEFINED_EVENT.
So nsDOMEvent::SetEventType works correctly, imo.
Submit event may have a bug, though nsFormEvent::originator couldn't
be set anyway, when dispatching an event manually.
btw, Bug 344986 fixes this bug too.
Depends on: 344986
> Since "wrong" event is created, it should be marked NS_USER_DEFINED_EVENT.

But there's no way to create the "right" event... 

> btw, Bug 344986 fixes this bug too.

Oh, nice!
(In reply to comment #23)
> > Since "wrong" event is created, it should be marked NS_USER_DEFINED_EVENT.
> 
> But there's no way to create the "right" event... 
> 

createEvent("UIEvents").
See also http://lxr.mozilla.org/seamonkey/source/layout/forms/nsTextControlFrame.cpp#2566


So does using that in the existing testcase work on trunk without any Gecko code changes?
Seems to work, yes.
In that case this is just invalid.  Though we really should document better what event types our various events are...
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → INVALID
I'm not sure I understand. Why is this bug invalid? Is it rather a valid bug that happens to be fixed in bug 344986 as mentioned in comment 22?
> Why is this bug invalid?

Because the wrong argument was being passed to createEvent.  "input" events are not in the "HTMLEvents" module but in the "UIEvents" module in Gecko...  (Note that "input" is not in the HTMLEvents list in DOM2 Events.)
But bug 344986 changes event handling so that 
it doesn't care about whether event is created using "right"
eventtype as a parameter for createEvent.
Unless I misunderstand something, this is a valid bug then. If not:
1) Does this mean one cannot create and dispatch a custom event with a made up name after creating it using document.createEvent("Events")? E.g.:
 var evt = document.createEvent("Events");
 evt.initEvent("test-event", true, false);
 // register a listener and dispatch the event

2) Even if I specified a clearly wrong event type to createEvent (say, MouseEvents), then tried to initEvent an 'input' event. It would be nicer if there was an explicit exception or something instead of just eating the event.
(Is it valid for JS code to pass 'wrong' type to initEvent?)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: