627726 - input event should not be cancelable

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Mounir Lamouri (:mounir)]

That's what requires WHATWG HTML specs and that's what Opera and Webkit do. It should be safe (wrt the web) to do that but should probably be done after Gecko 2.0 release.

Comment 1

[Mounir Lamouri (:mounir)]

To fix that, you have to call points sending the input event and change 'aCancelable' boolean from PR_TRUE to PR_FALSE. Maybe even changes call to use nsContentUtils::DispatchTrustedEvent.

I'm not sure I remember all points where the input event is fired but I think the only place is here:
nsTextControlFrame::FireOnInput

Tests will be necessary.

Comment 2

[nattofriends]

Hi,

I was looking at bug 615833 and wondered why when calling DispatchTrustedEvent instead, that the second to last parameter is true. Isn't that parameter aCancelable, which according to the bug should be instead false?

Comment 3

[Mounir Lamouri (:mounir)]

(In reply to Timothy Zhu from comment #2)
> I was looking at bug 615833 and wondered why when calling
> DispatchTrustedEvent instead, that the second to last parameter is true.
> Isn't that parameter aCancelable, which according to the bug should be
> instead false?

There is actually an optional parameter which is not passed here so when the method is called, the second to last parameter is aCanBubble and the last is aCancelable.
Note that this comment would have fit better in the original bug (bug 615833). No big deal though.

Comment 4

[Timothee GARNAUD]

(WIP) We are working on it. A patch is coming soon.

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

If Timothee is working on this bug, please set the assignee field and the status to ASSIGNED.

And nsTextControlFrame::FireOnInput() and nsEventNameList.h are using nsUIEvent. It causes making nsDOMUIEvent. However, HTML5 spec said:

http://dev.w3.org/html5/spec/common-input-element-apis.html#common-event-behaviors
> When the input event applies, any time the user causes the element's value
> to change, the user agent must queue a task to fire a simple event that
> bubbles named input at the input element.

http://dev.w3.org/html5/spec/webappapis.html#fire-a-simple-event
> Firing a simple event named e means that an event with the name e,
> which does not bubble (except where otherwise stated) and is not cancelable
> (except where otherwise stated), and which uses the Event interface,
> must be created and dispatched at the given target.

and detail attribute of input event doesn't make sense (always 0).

So, probably, you can use nsEvent and NS_EVENT instead of nsUIEvent and NS_UI_EVENT easily. Would you change them too?

Comment 6

[Mounir Lamouri (:mounir)]

I guess using DispatchTrustedEvent as suggested in comment 1 would fix that, wouldn't it?

Comment 7

[Timothee GARNAUD]

Attachment: (Work In Progress) This patch should correct that. r?

A test patch for this bug has been add.

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Mounir Lamouri (:volkmar) (:mounir) from comment #6)
> I guess using DispatchTrustedEvent as suggested in comment 1 would fix that,
> wouldn't it?

nsTextControlFrame::FireOnInput() also dispatches untrusted input event. So, nsContentUtils::DispatchTrustedEvent() cannot be useable there.

Comment 9

[Mounir Lamouri (:mounir)]

(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #8)
> nsTextControlFrame::FireOnInput() also dispatches untrusted input event. So,
> nsContentUtils::DispatchTrustedEvent() cannot be useable there.

Oups, I didn't see that...
Maybe we should add a ::DispatchUntrustedEvent() and ::DispatchEvent() which takes a aTrusted parameter to make this easier. Timothee, would you be interesting to do that? I'm going to open a bug. That should be quite straightforward I believe.

Comment 10

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

This was fixed on Fx14, see bug 668606.