Re: [blink-dev] Intent to Ship: Canvas Hit Regions

[Rick Byers]

Sorry for the delay, I wanted to take some time to understand this feature better - given my team's involvement in input and hit-testing.  /cc input-dev as FYI there.

On Tue, Jan 19, 2016 at 10:19 AM, Justin Novosad <ju...@chromium.org> wrote:

On Tue, Jan 19, 2016 at 8:36 AM, Philip Jägenstedt <phi...@opera.com> wrote:

On Fri, Jan 8, 2016 at 11:28 PM, Justin Novosad <ju...@chromium.org> wrote:

On Fri, Jan 8, 2016 at 5:09 PM, Rick Byers <rby...@chromium.org> wrote:

On Fri, Jan 8, 2016 at 11:15 AM, Justin Novosad <ju...@chromium.org> wrote:

Hmm... the Blink implementation also adds the 'region' attribute to TouchEvent which is not in the W3C spec, and it also has the fillRule option.

 Can you point me to more details about the TouchEvent change?  I quickly searched / skimmed the spec and current implementation in ToT, but I haven't yet found what you're referring to here.

Yeah... you kinda need to know what to look for. The code is implemented as a partial interface in the canvas2D module:

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/modules/canvas2d/TouchHitRegion.cpp&sq=package:chromium&type=cs

See also the EventHitRegion and MouseEventHitRegion classes

Thanks, I found the IDL files and from there the relevant spec sections:

https://html.spec.whatwg.org/multipage/scripting.html#MouseEvent-partial

https://html.spec.whatwg.org/multipage/scripting.html#Touch-partial

I see that the MouseEventInit extensions aren't in Blink, can you add that before shipping?

Good catch! Filed a bug that is blocking the launch bug: crbug.com/579076

(The reason that TouchInit isn't extended is because Touch.prototype.region is defined (and implemented) to return a value based on the touch location, and not the value of an internal slot like MouseEvent.)

That looks like a spec bug to me - probably because we only recently standardized TouchInit.  I filed https://github.com/whatwg/html/issues/547 for this.  Ideally this can be added quickly to the spec and blink implementation, but if not I wouldn't block shipping on that.

But there seem to be other problems here.  Our current implementation for "region" on both MouseEvent and Touch appear to use the pointer's current location.  For touch this doesn't appear to match the spec, which says: "The region attribute on a Touch object representing a touch point T must return the value obtained by running the following algorithm when T was first placed on the surface".  This spec text makes sense because touch events are defined to have "implicit capture" meaning they do a hit-test only at touchstart time, and then following touchmove/touchend events are targetted at the same element that received the touchstart (no new hit-test).  It sounds like Touch.region is defined to match this implicit capture semantics of the events, but our implementation doesn't appear to be doing that.  I filed https://crbug.com/579614 to track this.  I think this probably should block shipping since the behavior difference could cause a bunch of problems / confusion for web developers.

There's also a bunch of strange inconsistencies in the spec between the Touch and MouseEvent case (which don't appear to be reflected in our implementation).  I filed https://github.com/whatwg/html/issues/548 for those.  This doesn't need to block shipping itself IMHO, but it suggests that there may be interop issues here.  Does Firefox really match the spec wrt. the differences between Mouse and Touch behavior?  In which cases do we match the spec vs. match mouse behavior (the implementation looks like Mouse and Touch behave identically - which seems like the right model to me).

LGTM1 to ship!