Last Comment Bug 627726 - input event should not be cancelable
: input event should not be cancelable
Status: RESOLVED FIXED
[mentor=volkmar][lang=c++]
:
Product: Core
Classification: Components
Component: DOM: Core & HTML (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla14
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on: 668606 718274
Blocks:
  Show dependency treegraph
 
Reported: 2011-01-21 08:04 PST by Mounir Lamouri (:mounir)
Modified: 2012-07-17 19:32 PDT (History)
6 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
(Work In Progress) This patch should correct that. r? (1.09 KB, patch)
2012-01-10 10:19 PST, Timothee GARNAUD
no flags Details | Diff | Splinter Review

Description Mounir Lamouri (:mounir) 2011-01-21 08:04:59 PST
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) 2011-09-15 10:44:07 PDT
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 Timothy Zhu 2011-11-06 16:27:35 PST
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) 2011-11-18 03:26:00 PST
(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 2011-12-13 01:01:45 PST
(WIP) We are working on it. A patch is coming soon.
Comment 5 Masayuki Nakano [:masayuki] (Mozilla Japan) 2012-01-09 17:22:48 PST
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) 2012-01-10 06:14:51 PST
I guess using DispatchTrustedEvent as suggested in comment 1 would fix that, wouldn't it?
Comment 7 Timothee GARNAUD 2012-01-10 10:19:06 PST
Created attachment 587362 [details] [diff] [review]
(Work In Progress) This patch should correct that. r?

A test patch for this bug has been add.
Comment 8 Masayuki Nakano [:masayuki] (Mozilla Japan) 2012-01-10 17:32:16 PST
(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) 2012-01-15 03:23:32 PST
(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] (Mozilla Japan) 2012-07-17 19:26:06 PDT
This was fixed on Fx14, see bug 668606.

Note You need to log in before you can comment on or make changes to this bug.