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

On Thu, Jan 22, 2015 at 7:34 AM, Olli Pettay <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>> wrote:
>>
>>     On Tue, Jan 20, 2015 at 4:31 PM, Rick Byers <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.  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.

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()>() 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/
>>
>>
>>
>