Fix conditional TouchEvent creation support

Fix conditional TouchEvent creation support

Prior to M2, document.createEvent("TouchEvent") would only succeed when touch support was enabled (eg. we detected a touch screen).  Some websites use this as a signal that a touch screen is present.  In M32 the location of TouchEvent.idl moved (http://src.chromium.org/viewvc/blink?view=revision&revision=158219) but the old path was still used in EventAliases.idl, and this caused the generated Event.cpp code to have redundant entries making the RuntimeEnabled annotation useless:

   if (type == "TouchEvent")
        return TouchEvent::create();
   if (type == "TouchEvent" && RuntimeEnabledFeatures::touchEnabled())
        return TouchEvent::create();

This change fixes that problem by updating EventAliases.idl with the correct path.

This also updates the code generation scripts to flag this sort of mistake an error.  Normally an incorrectly typed name in the EventAliases.in file would result in a compile error when we try to include the relevant header file.  However the support for 'aliases' requires that when we see a second entry for the same cpp_name (class name) we don't try to include header files for it again (we rely on the fact that we don't need to know the full path in this case).  So we just flag an error whenever we see multiple entries with the same script_name.

Note that we probably can't just make the entire TouchEvent interface RuntimeEnabled because even when touch support is disabled, chrome dev tools can be used to emulate touch and create instances of TouchEvent objects.  Ultimately touch events should really be supported all the time, but that's a larger issue with site compatibility issues.

BUG=332588
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=165361

[Rick Byers, 2014-01-14 04:49:05]

Eric, please review this trivial tweak (minor update to your dom->events move
back in September).  

I was tempted not to fix this since it's already an unfortunate compat hack (JS
event-creation being conditional on hardware), and we're just about to ship it
to stable and apparently the world hasn't blown up.  But the fix is trivial and
I guess it's consistent with the other compat hacks ('ontouchstart' in window,
etc.).

I considered trying to add a test for this (this isn't covered by WebExposed
since we're not changing the existence of the window.TouchEvent constructor -
it's always there).  But I'm not sure it's worth it (would need new machinery
for running tests with and without touchscreen support enabled).   
WDYT?

Rick

[eseidel, 2014-01-15 20:17:06]

Can you please fix the script to validate that the files at that path exist? 
That will prevent this from happening again in the future. :)

[Rick Byers, 2014-01-15 22:05:11]

On 2014/01/15 20:17:06, eseidel wrote:
> Can you please fix the script to validate that the files at that path exist? 
> That will prevent this from happening again in the future. :)

Yes of course - good idea (better than the specific test I was considering
trying to add).  Thanks.

[Rick Byers, 2014-01-17 21:57:15]

On 2014/01/15 22:05:11, Rick Byers wrote:
> On 2014/01/15 20:17:06, eseidel wrote:
> > Can you please fix the script to validate that the files at that path exist?

> > That will prevent this from happening again in the future. :)
> 
> Yes of course - good idea (better than the specific test I was considering
> trying to add).  Thanks.

Done - although it wasn't as simple as making sure the path exists (the compiler
would normally do that for us anyway).  See updated CL description for an
explanation of why I added the validation this way.

[eseidel, 2014-01-17 22:52:35]

lgtm

[commit-bot: I haz the power, 2014-01-17 22:52:52]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/rbyers@chromium.org/137313004/70001

[commit-bot: I haz the power, 2014-01-18 02:14:55]

Retried try job too often on win_blink_rel for step(s) webkit_tests
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win_blink_...

[commit-bot: I haz the power, 2014-01-18 03:23:09]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/rbyers@chromium.org/137313004/70001

[commit-bot: I haz the power, 2014-01-18 05:00:27]

Change committed as 165361