This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 25405 - Input Event Types (some correct)
Summary: Input Event Types (some correct)
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - DOM3 Events (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Travis Leithead [MSFT]
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-04-21 18:42 UTC by Arkadiusz Michalski (Spirit)
Modified: 2014-05-07 23:54 UTC (History)
2 users (show)

See Also:


Attachments

Description Arkadiusz Michalski (Spirit) 2014-04-21 18:42:49 UTC
In table (5.1.1 List of DOM3 Event Types) beforeinput event has this:
Default Action: 
None

But definition beforeinput event has some default action (https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#event-type-beforeinput).

Definition table for beforeinput and input should have this (in Context info)

UIEvent.view
UIEvent.detail

All event types implement (or inherit) UIEvent list this property in their tables. 

And this tables should also include InputEvent.isComposing attribute.

InputEvent.data description in table probably is not complete (when comparing with HTML5). In HTML5 we have only input event type, and it can be fired additionally for input type=checkbox/type=radio or select, and in this case what value is appropriate - empty string or null? On the other hand, HTML5 does not take into account the InputEvent interface for input event (just inherit from Event). At now only Firefox started implement this interface (with some objection due to the HTML5: https://bugzilla.mozilla.org/show_bug.cgi?id=970802).

According above HTMLSelectElement should be trate as a target for this event type.

In description for data attribute we have:
[data of type DOMString, readonly
    ...This attribute MAY be null or contain the empty string.]

What exactly means null? If nullable type then definition in interface and dictionary should have '?' after DOMString (DOMString?).
Comment 1 Travis Leithead [MSFT] 2014-04-23 00:47:35 UTC
I'll take a look a this one...
Comment 2 Arkadiusz Michalski (Spirit) 2014-04-27 21:22:41 UTC
About 'data' and nullable type:

CompositionEvent.data << nullable
InputEvent.data << not nullable

All other DOMString attributes are not nullable. In all cases default is empty string and wondering if null is really returned in any case for above attributes.

And in the very similar case:

partial interface CompositionEvent {
    // Originally introduced (and deprecated) in DOM Level 3
    void initCompositionEvent (DOMString typeArg, boolean bubblesArg, boolean cancelableArg, Window? viewArg, DOMString? dataArg, DOMString? locale);
};

"locale" in this method is nullable, but in UIEvents not (https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm#composition-event-interface).
Comment 3 Arkadiusz Michalski (Spirit) 2014-04-30 04:10:01 UTC
I check this more closely and:

===

In initCompositionEvent() 
DOMString? locale >> should be change to DOMString locale

Created untrusted event (with locale = null in initCompositionEvent or constructor) and getting e.locale return string.

<script>

 var ev = document.createEvent("CompositionEvent");
 ev.initCompositionEvent("hellow", true, true, window, null, null);

 document.write(ev);
 document.write("<br>");
 document.write(ev.locale === null); // false (IE/Firefox, Chrome doesn't suport .locale)

</script>

===

.data is more interesting, now we don't have suport it on InputEvent interface, but work in CompositionEvent interface (in FF, Chrome, IE).

Below works only in Chrome
<script>
 var ev = new CompositionEvent("hello", {
  data: null
 });

 document.write(ev);
 document.write("<br>");
 document.write(ev.data === null); // false
</script> 

Below works in Chrome/IE and Firefox
<script>
 var ev = document.createEvent("CompositionEvent");
 ev.initCompositionEvent("hellow", true, true, window, null, null);

 document.write(ev);
 document.write("<br>");
 document.write(ev.data === null); // false (IE/Chfome), true (Firefox) 
</script>

Only Firefox respect nullable and I wonder if it should be for some reason, or just a small mistake in the specification that has been implemented.
Comment 4 Travis Leithead [MSFT] 2014-05-05 21:46:01 UTC
(In reply to spiritRKS1910 from comment #0)
> In table (5.1.1 List of DOM3 Event Types) beforeinput event has this:
> Default Action: 
> None
> 
> But definition beforeinput event has some default action
> (https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#event-
> type-beforeinput).

Yep. I will make this consistent.


> Definition table for beforeinput and input should have this (in Context info)
> 
> UIEvent.view
> UIEvent.detail
> 
> All event types implement (or inherit) UIEvent list this property in their
> tables. 

I will add these. Good find.


> And this tables should also include InputEvent.isComposing attribute.

Yep. This was added recently, but we forgot to update the tables. Good catch.

> InputEvent.data description in table probably is not complete (when
> comparing with HTML5). In HTML5 we have only input event type, and it can be
> fired additionally for input type=checkbox/type=radio or select, and in this
> case what value is appropriate - empty string or null? On the other hand,
> HTML5 does not take into account the InputEvent interface for input event
> (just inherit from Event). At now only Firefox started implement this
> interface (with some objection due to the HTML5:
> https://bugzilla.mozilla.org/show_bug.cgi?id=970802).
> 
> According above HTMLSelectElement should be trate as a target for this event
> type.

I think I will make this more generic, limiting the trusted event targets to "Element" and then in the event definition, calling out that these are control type elements as well as contenteditable element. The umbrella "Element" covers all these cases.
Comment 5 Travis Leithead [MSFT] 2014-05-05 21:55:35 UTC
Regarding nullable DOMString locale and data: I think that these all need to be non-nullable, and that the prose indicating that it can be null needs to be changed to match the IDLs. I'll do a pass through these to make sure that they are consistent.
Comment 6 Travis Leithead [MSFT] 2014-05-05 22:03:49 UTC
I've made these fixes now.

Changelist: https://dvcs.w3.org/hg/dom3events/rev/937b13a68529
Comment 7 Arkadiusz Michalski (Spirit) 2014-05-06 15:30:01 UTC
Still exist in Input:

[data of type DOMString, readonly
    ...This attribute MAY be null or contain the empty string.]

Just [This attribute MAY be the empty string.] like in CompositionEvent.
Comment 8 Travis Leithead [MSFT] 2014-05-07 23:54:01 UTC
Great catch. I think I have them all now:
https://dvcs.w3.org/hg/dom3events/rev/14b8c9f6caa0