2.86 KB, application/vnd.mozilla.xul+xml
2.52 KB, text/html
1.47 KB, patch
|Details | Diff | Splinter Review|
2.31 KB, text/html
2.52 KB, text/html
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
14 years ago
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?
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. :-)
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.
13 years ago
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 > alert('dispatchEvent \'' + type + '\' to \'' + target_id + '\' done, bubble = ' + bubble ..... Typo in attachments displayed code: target_i, not id
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.
(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
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
Last Resolved: 13 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.