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 25491 - createEvent and case significance
Summary: createEvent and case significance
Status: RESOLVED WONTFIX
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: DOM (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: Anne
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-04-28 14:19 UTC by Erik Arvidsson
Modified: 2014-05-05 15:51 UTC (History)
9 users (show)

See Also:


Attachments

Description Erik Arvidsson 2014-04-28 14:19:19 UTC
Blink/WebKit do not supports lowercase names for the interface argument.

http://dom.spec.whatwg.org/#dom-document-createevent

It therefore seems like the open web cannot depend on this and therefore we should be able to clean up the spec a bit.

Notice that engines all allow a trailing 's' on the interface name.
Comment 1 Anne 2014-04-28 14:24:19 UTC
So we should only have these:

* CustomEvent	
* Event
* Events
* HTMLEvents
* MouseEvent
* MouseEvents
* UIEvent
* UIEvents

Right?

I.e. we won't add CustomEvents or HTMLEvent.
Comment 2 Erik Arvidsson 2014-04-28 14:30:37 UTC
Looks correct to me.

It is not clear to me that this list is extensible by other specs.
Comment 3 Anne 2014-04-28 15:16:55 UTC
The idea is for it to not be extensible. I realize we may have to add more names, it's currently conservative.
Comment 4 Robin Berjon 2014-04-28 15:18:33 UTC
FWIW here are the current test results for this:

http://w3c.github.io/dom/test-results/all.html#test-file-50
Comment 5 Olli Pettay 2014-04-28 17:27:38 UTC
What is wrong with the current spec which says case-insensitive comparison.


Engines allow trailing 's' on some old interface names.
Comment 6 Erik Arvidsson 2014-04-28 17:46:04 UTC
(In reply to Olli Pettay from comment #5)
> What is wrong with the current spec which says case-insensitive comparison.

I was hoping we could remove this quirks to make things simpler since it is very unlikely that any web content depends on this.

> Engines allow trailing 's' on some old interface names.

We still need to allow that.
Comment 7 Simon Pieters 2014-04-29 07:07:16 UTC
In webdevdata data set 2013-09-01 102,000 pages I see the following instances that don't match those in comment 1 (there were 616 createEvents in total):

"TouchEvent"
'KeyEvents'
"TouchEvent"
'MessageEvent'
"TouchEvent"
'TouchEvent'
"TouchEvent"
"TouchEvent"
"TouchEvent"
"TouchEvent"
"TouchEvent"

So from this data it seems it doesn't need to be case-insensitive, but possibly some values should be added (TouchEvent?).

$ find . -type f -print0 | xargs -0 -P 4 -n 40 grep -E "\.createEvent\s*\(\s*[\"'][a-zA-Z]+[\"']" >> ../createEvent.txt
$ grep -Ec "\.createEvent\s*\(\s*[\"'][a-zA-Z]+[\"']" createEvent.txt
616
$ grep -Ev "\.createEvent\s*\(\s*[\"'](CustomEvent|Event|Events|HTMLEvents|MouseEvent|MouseEvents|UIEvent|UIEvents)[\"']" createEvent.txt > other-createEvent.txt
Comment 8 Rob Buis 2014-04-30 22:44:04 UTC
(In reply to Simon Pieters from comment #7)
> In webdevdata data set 2013-09-01 102,000 pages I see the following
> instances that don't match those in comment 1 (there were 616 createEvents
> in total):
> 
> "TouchEvent"
> 'KeyEvents'
> "TouchEvent"
> 'MessageEvent'
> "TouchEvent"
> 'TouchEvent'
> "TouchEvent"
> "TouchEvent"
> "TouchEvent"
> "TouchEvent"
> "TouchEvent"
> 
> So from this data it seems it doesn't need to be case-insensitive, but
> possibly some values should be added (TouchEvent?).
> 
> $ find . -type f -print0 | xargs -0 -P 4 -n 40 grep -E
> "\.createEvent\s*\(\s*[\"'][a-zA-Z]+[\"']" >> ../createEvent.txt
> $ grep -Ec "\.createEvent\s*\(\s*[\"'][a-zA-Z]+[\"']" createEvent.txt
> 616
> $ grep -Ev
> "\.
> createEvent\s*\(\s*[\"'](CustomEvent|Event|Events|HTMLEvents|MouseEvent|Mouse
> Events|UIEvent|UIEvents)[\"']" createEvent.txt > other-createEvent.txt

I have also seen examples that refer to "KeyboardEvent":

https://developer.mozilla.org/en-US/docs/Web/API/event.initKeyEvent

Not sure how many websites out there use it though.

Also I wonder why there are tests to verify that createEvent("ProgressEvent") is not possible? Is it special and needs as test compared to the above?
Comment 9 Anne 2014-05-01 09:43:01 UTC
We should probably have tests for all event interfaces that are not supported in the legacy createEvent() API. Having one for ProgressEvent seems like a good start.
Comment 10 Rob Buis 2014-05-01 11:05:43 UTC
(In reply to Anne from comment #9)
> We should probably have tests for all event interfaces that are not
> supported in the legacy createEvent() API. Having one for ProgressEvent
> seems like a good start.

I was just surprised that ProgressEvent has its own test:
http://www.w3c-test.org/dom/events/ProgressEvent.html

It seems to me writing a test for every possible event interface out there is not practical, unless there is whitelisting.
Comment 11 Anne 2014-05-01 11:15:46 UTC
Well we know all the event interfaces in the platform. And they do all need tests. Adding a line for whether or not it should work through the createEvent() API does not seem like a big deal.
Comment 12 Travis Leithead [MSFT] 2014-05-01 17:24:05 UTC
(In reply to Erik Arvidsson from comment #0)
> Blink/WebKit do not supports lowercase names for the interface argument.
> 
> http://dom.spec.whatwg.org/#dom-document-createevent
> 
> It therefore seems like the open web cannot depend on this and therefore we
> should be able to clean up the spec a bit.
> 
> Notice that engines all allow a trailing 's' on the interface name.

IE _does_ support all lowercase names. For example:
  document.createEvent("mouseevent") 
gives you an instance of the MouseEvent constructor. 

Is "clean up the spec" really the motivation for this?

Even if the spec was tightened up to not allow this, I'm not sure it really matters enough to risk any compatibility impact to change our implementation in the near future.
Comment 13 Olli Pettay 2014-05-02 21:51:19 UTC
(In reply to Travis Leithead [MSFT] from comment #12)
> Even if the spec was tightened up to not allow this, I'm not sure it really
> matters enough to risk any compatibility impact to change our implementation
> in the near future.
I could say the same about Gecko.
Comment 14 Anne 2014-05-04 08:46:57 UTC
Fair, ASCII case-insensitive does not seem too bad given that the list of names is restricted and its a legacy API anyway.
Comment 15 Erik Arvidsson 2014-05-05 15:51:44 UTC
Fair enough.