Re: [DOM3Events] Identifying mouse events derived from touch events

On Thu, Jan 22, 2015 at 11:26 AM, Olli Pettay <olli@pettay.fi> wrote:

> On 01/22/2015 06:21 PM, Olli Pettay wrote:
>
>> On 01/22/2015 05:55 PM, Rick Byers wrote:
>>
>>> On Thu, Jan 22, 2015 at 7:34 AM, Olli Pettay <olli@pettay.fi <mailto:
>>> olli@pettay.fi>> wrote:
>>>
>>>     On 01/22/2015 06:09 AM, Rick Byers wrote:
>>>
>>>         On Tue, Jan 20, 2015 at 10:59 AM, Anne van Kesteren <
>>> annevk@annevk.nl <mailto:annevk@annevk.nl> <mailto:annevk@annevk.nl
>>>         <mailto:annevk@annevk.nl>>> wrote:
>>>
>>>              On Tue, Jan 20, 2015 at 4:31 PM, Rick Byers <
>>> rbyers@chromium.org <mailto:rbyers@chromium.org> <mailto:
>>> rbyers@chromium.org
>>>         <mailto:rbyers@chromium.org>>> wrote:
>>>              > Is my earlier proposal (a single "derivedFromTouchEvent"
>>> bool on Mouse
>>>              > events) preferable in your opinion?  Or does it just
>>> suffer from the exact
>>>              > same problem?
>>>
>>>              I think that might be better as it is more scoped. Since we
>>> don't
>>>              really understand this space much from a theoretical
>>> perspective I
>>>              would be hesitant to add generic APIs.
>>>
>>>
>>>         Understood, thanks.  Jacob, you are the strongest proponent for
>>> the 'firedFrom' model over the 'derivedFromTouchEvent' one.  Any thoughts?
>>>
>>>         Here's a 3rd option we haven't discussed in detail yet:
>>>
>>>         What if input events all had a 'sourceDevice' attribute which
>>> returned an object with an attribute like 'firesTouchEvents'.
>>>
>>>
>>>     In Gecko MouseEvents have the non-standard 'readonly attribute
>>> unsigned short mozInputSource;'
>>>     and the value can be MOZ_SOURCE_UNKNOWN, MOZ_SOURCE_MOUSE,
>>> MOZ_SOURCE_PEN etc.
>>>
>>>     enum InputEventSource {
>>>        "",
>>>        "touch",
>>>        "mouse"
>>>        "pen",
>>>        "keyboard" // for 'enter' key event triggering 'click'
>>>     };
>>>     readonly attribute InputEventSource inputSource;
>>>
>>>     might work pretty well.
>>>
>>>
>>> Just exposing the type of source device is insufficient.  Eg. in IE
>>> desktop the source device is touch, but since it didn't generate any touch
>>> events
>>> the logic shouldn't assume touch event handlers have run.
>>>
>>
>> We shouldn't use this thing for feature detection. If touch events aren't
>> supported, they aren't.
>> But the source can still be touch.
>> For feature detection, ("TouchEvent" in window) should work.
>>
>
Right ('TouchEvent' in window) says whether the browser supports the touch
event feature.  Chrome ALWAYS supports the touch event feature (eg. you can
open devtools on any device and send touch events).

 Conversely Firefox for Android fires touch events for a mouse, so even
>>> though the actual
>>> source device was a mouse, app logic should still expect the mouse
>>> events to be redundant with touch events.
>>>
>> Why, if also mouse events are fired?
>>
> I mean, if we add inputSource also to TouchEvents/PointerEvents, then it
> is up to the application logic to decide what to do with the events.


Imagine an application that causes a button to be depressed on touchstart
and mousedown.  The question we're trying to answer here is how to avoid
triggering both the 'mousedown' and 'touchstart' logic for the same user
action without modifying any global event state (i.e. calling
preventDefault).  If we do this right, then it should even work for complex
scenarios like simultaneously tapping on the touchscreen and clicking with
a real mouse on a touchscreen laptop.  In this design, the application code
could be written like:

button.addEventListener('touchstart', depressButton);
button.addEventListener('mousedown', function(e) {
  if (!e.sourceDevice.firesTouchEvents)
    depressButton(e);
});

What would similar app code look like for the design you envision?

So we need some indication about the relationship between events types.
>>> But doing this via some InputDevice object seems like good step forward
>>> along
>>> a path we wanted to go down anyway.
>>>
>>>     I wouldn't add derivedFromTouchEvent. That makes the APIs depend on
>>> each others too much, and given we probably want to expose
>>>     different derivedFrom values too, it would easily become very ugly.
>>>
>>>
>>>
>>>     -Olli
>>>
>>>           I've argued that the
>>>         problem here is NOT one of source device but of related events,
>>> but if the source device says explicitly what event types it fires and
>>>         developers test
>>>         that (rather than inferring it from some "device class") then
>>> that's just as good.
>>>
>>>         In the pointer events working group we had other reasons to want
>>> an input device API (eg. 'navigator' is really a poor place for
>>>         'maxTouchPoints').
>>>         Perhaps this is as good as a reason as any to start exposing an
>>> input device properties object.  I wouldn't argue here for hanging a bunch
>>> of
>>>         extra
>>>         stuff of it, but it's reasonable to think that over time we'll
>>> want an API surface like this.  Most other platforms have such a facility
>>> (eg.
>>>         MotionEvent.getDevice <http://developer.android.com/
>>> __reference/android/view/__InputEvent.html#getDevice()
>>>         <http://developer.android.com/reference/android/view/
>>> InputEvent.html#getDevice()>>() on Android).
>>>
>>>              As your document suggests it is unclear what to include.
>>> Which also
>>>              suggests it does not fall out automatically from some
>>> underlying
>>>              primitive. Rather, we do this in various places as
>>> localized hacks and
>>>              there is probably not a generic framework that encompasses
>>> them well.
>>>
>>>
>>>         Yes, I agree this is a good legitimate argument against this
>>> design.
>>>
>>>              > That said, if this group is interested in trying to spec
>>> this out in detail,
>>>              > I'm happy to help from the chromium side (explaining our
>>> implementation,
>>>              > trying to tweak it to align with the model you all agree
>>> on, etc.).
>>>
>>>              I've been trying to get the people defining UI Events to do
>>> this for a
>>>              while now without much success.
>>>
>>>
>>>              --
>>>         https://annevankesteren.nl/
>>>
>>>
>>>
>>>
>>>
>>
>