input event should not be cancelable

RESOLVED FIXED in mozilla14

Status

()

Core
DOM: Core & HTML
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: mounir, Unassigned)

Tracking

Trunk
mozilla14
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [mentor=volkmar][lang=c++])

Attachments

(1 attachment)

(Reporter)

Description

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

Comment 1

6 years ago
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.
Whiteboard: [mentor=volkmar]

Comment 2

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

Comment 3

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

6 years ago
(WIP) We are working on it. A patch is coming soon.
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?
(Reporter)

Comment 6

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

Comment 7

6 years ago
Created attachment 587362 [details] [diff] [review]
(Work In Progress) This patch should correct that. r?

A test patch for this bug has been add.
Attachment #587362 - Flags: review?
(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.
(Reporter)

Comment 9

5 years ago
(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.
Whiteboard: [mentor=volkmar] → [mentor=volkmar][lang=c++]
(Reporter)

Updated

5 years ago
Depends on: 718274
(Reporter)

Updated

5 years ago
Attachment #587362 - Flags: review?
This was fixed on Fx14, see bug 668606.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Depends on: 668606
Resolution: --- → FIXED
Target Milestone: --- → mozilla14
You need to log in before you can comment on or make changes to this bug.