W3C TouchEvent spec conformance tests (http://w3c-test.org/webevents/tests/touch-events-v1/submissions/Mozilla/single-touch.html) fail with: Interface names are correct. TouchList is not defined I.e., 'e instanceof TouchList' throws, even when e is in fact an instance of a TouchList. Maybe something wrong with the bindings here. Tested on ChromeOS and Android. I've also hear this fails on Nokia devices (qt port?)
Created attachment 175578 [details] Patch
Comment on attachment 175578 [details] Patch Looks fine, but we need a test. It should be very easy to test.
(In reply to comment #2) > (From update of attachment 175578 [details]) > Looks fine, but we need a test. It should be very easy to test. Thanks! I intentionally didn't set r? yet because I still needed a test (just trying to find out which pattern to follow for this sort of test - was a little confused by the existing window property tests, wanted to see what failed in EWS due to the new member - apparently nothing!). I should have included 'no for review' in the patch description.
Touch is also missing. TouchEvent exists.
Created attachment 175705 [details] Patch
Comment on attachment 175705 [details] Patch Clearing flags on attachment: 175705 Committed r135562: <http://trac.webkit.org/changeset/135562>
All reviewed patches have been landed. Closing bug.
I'm reverting this version (in bug 106071) as it broke a poorly written website's mobile device detection logic. Instead I think we should add these properties dynamically to temporarily mitigate the compat issue, exactly as we do for window.ontouchstart, etc.
Created attachment 181270 [details] Diff against ToT for testing
Created attachment 181271 [details] Diff against bug 106071 for review
This mostly just re-lands the original patch, except that I also mark all 3 touch event constructors (the 2 new ones, as well as window.TouchEvent) as V8EnabledAtRuntime. Rather than add 2 new runtime-enabled feature APIs, I consolodated them all under the single 'enableTouch' API. I tried to write a test that validates all these APIs are undefined when the runtime feature has been disabled, but it's not clear to me how to do it. Doing it in a LayoutTest via InternalSettings is too late - V8 has already created the window object, etc. I couldn't find any other example where this is tested (checked a few other V8EnabledAtRuntime features), and given the simplicity of the code I figure it's fine not to explicitly test that. Let me know if this is really worth trying to test explicitly.
Comment on attachment 181271 [details] Diff against bug 106071 for review LGTM
Created attachment 181351 [details] Patch for landing
Thanks!
Comment on attachment 181351 [details] Patch for landing Clearing flags on attachment: 181351 Committed r138843: <http://trac.webkit.org/changeset/138843>