|Summary:||initTouchEvent in TouchEvent.idl does not match the W3C Touch Events Specification editor's draft.|
|Product:||WebKit||Reporter:||Andy Estes <aestes>|
|Severity:||Normal||CC:||aestes, apandia.ttg, benjamin, benm, diegohcg, hausmann, joepeck, kenneth, laszlo.gombos, mbrubeck, mjs, tonikitoo, webkit.review.bot|
|Version:||528+ (Nightly build)|
|Bug Depends on:|
Description Andy Estes 2011-05-11 00:25:40 PDT
WebKit's current definition of initTouchEvent()  is incompatible with the W3C's Touch Events Specification editor's draft . We should update our definition to match the spec draft.  https://trac.webkit.org/browser/trunk/WebCore/dom/TouchEvent.idl?rev=52113#L40  https://dvcs.w3.org/hg/webevents/raw-file/tip/touchevents.html#touchevent-interface
Comment 1 Andy Estes 2011-05-12 14:10:07 PDT
FWIW, Apple's implementation of TouchEvent closely matches the W3C spec, with the exception of having two additional parameters at the end of initTouchEvent() (scale and rotation). See <http://developer.apple.com/library/safari/#documentation/UserExperience/Reference/TouchEventClassReference/TouchEvent/TouchEvent.html>.
Comment 2 Antaryami Pandia 2011-07-11 02:55:06 PDT
There are some more differences between apple's implementation and the W3C's touch events spec.The apple's implementation includes parameter as "screenX", "screenY", "clientX" and "clientY". Another related issue(https://bugs.webkit.org/show_bug.cgi?id=32484) is logged for qt port but involves changes to the initTouchEvent API signature.It is primarily for adding support for scale and transformation properties.
Comment 3 Matt Brubeck 2011-07-19 08:42:03 PDT
In the W3C Web Events working group, we are currently discussing whether the W3C Touch Events spec should be changed to be more compatible with current WebKit implementations. Some old discussion about createTouch and initTouchEvent here: http://www.w3.org/2010/webevents/track/issues/17 New discussion about initTouchEvent will be tracked here: http://www.w3.org/2010/webevents/track/issues/19 In particular, we are wondering whether it is necessary or useful to have screenX/Y and clientX/Y parameters to the initTouchEvent method (since coordinates in touch events are properties of each Touch object rather than the TouchEvent object itself). Are these parameters useful to authors using the interface, or are they just an artifact of how WebKit's implementation inherits from other interfaces? If they aren't useful, is it possible to remove them from WebKit? Feedback is welcome at http://lists.w3.org/Archives/Public/public-webevents/
Comment 4 Laszlo Gombos 2011-09-05 20:11:57 PDT
Created attachment 106378 [details] Remove screenX/Y and clientX/Y parameters from the initTouchEvent method This change aligns the interface with the latest W3C Touch Events Specification, but makes it different from exsiting Apple's iOS and Google's Android products.
Comment 5 WebKit Review Bot 2011-09-05 20:15:22 PDT
Attachment 106378 [details] did not pass style-queue: Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'LayoutTests/ChangeLog', u'LayoutTests/fast..." exit_code: 1 Source/WebCore/dom/TouchEvent.h:56: The parameter name "view" adds no information, so it should be removed. [readability/parameter_name]  Total errors found: 1 in 6 files If any of these errors are false positives, please file a bug against check-webkit-style.
Comment 6 Laszlo Gombos 2011-09-05 20:24:14 PDT
Created attachment 106379 [details] same as previous + fix style
Comment 7 Matt Brubeck 2011-10-04 10:19:46 PDT
The Web Events working group has decided to remove the initTouchEvent method from the spec, and add a DOM4-style constructor instead. See this issue for discussion and links: http://www.w3.org/2010/webevents/track/issues/23 So this patch is no longer needed, and this issue can be resolved as INVALID.
Comment 9 Adam Barth 2011-10-15 00:07:45 PDT
Comment on attachment 106379 [details] same as previous + fix style Cleared review? from attachment 106379 [details] so that this bug does not appear in http://webkit.org/pending-review. If you would like this patch reviewed, please attach it to a new bug (or re-open this bug before marking it for review again).