W3C home > Mailing lists > Public > public-pointer-events@w3.org > July to September 2014

Re: IE implementation of navigator.maxTouchPoints

From: Nikolay Lebedev <nicklebedev37@gmail.com>
Date: Fri, 12 Sep 2014 10:59:56 +0400
Message-ID: <CAKjBLmHh5paaZ4QCPfATudm1-wSadBk1jnwccc7HjsUeW3Cbew@mail.gmail.com>
To: Rick Byers <rbyers@chromium.org>, "public-pointer-events@w3.org" <public-pointer-events@w3.org>
Hi Rick,

no, maxTouchPoints is enabled by the same preference value as the pointer
events. I agree that touch events aren't actually involved, sorry for
confusion. Given that Firefox with enabled pointer events preference (which
isn't turned on by default) may behave the same way as Chrome on the broken
sites.

Thanks,
Nick

On Thu, Sep 11, 2014 at 11:15 PM, Rick Byers <rbyers@chromium.org> wrote:

> On Thu, Sep 11, 2014 at 2:55 PM, Nikolay Lebedev <nicklebedev37@gmail.com>
> wrote:
>
>> Hi guys,
>>
>> btw, mozilla firefox has likely the same issue as Chrome:
>> http://mxr.mozilla.org/mozilla-central/source/widget/windows/nsWindow.cpp#3611
>> :). But afaik it doesn't have touch events enabled yet on desktop/win7 and
>> likely such issue doesn't break anything.
>>
>> Anyway i'll file a bug in firefox's bugzilla to track it.
>>
>
> Thanks Nick!  Do you have the maxTouchPoints API enabled even when
> touch/pointer events aren't enabled?  The complaint of Chrome users was
> ultimately due to (IMHO broken) sites that were changing their
> layout/functionality because they thought the users had a touch screen (and
> so MUST be a "tablet").  So touch events aren't actually involved at all.
>
>
>> Thanks,
>> Nick
>>
>> On Thu, Sep 11, 2014 at 10:36 PM, David Bokan <bokan@google.com> wrote:
>>
>>> Beat me to the punch: https://codereview.chromium.org/563853002
>>>
>>> On Thu, Sep 11, 2014 at 2:31 PM, Rick Byers <rbyers@chromium.org> wrote:
>>>
>>>> Essentially yes (although I don't think that compiles - you mean
>>>> IsTouchDevicePresent, not IsTouchEnabledDevice?).  I believe bokan@
>>>> plans to land something like this ASAP.
>>>>
>>>> Thanks,
>>>>    Rick
>>>>
>>>>
>>>> On Thu, Sep 11, 2014 at 1:29 AM, Sangwhan Moon <smoon@opera.com> wrote:
>>>>
>>>>> Makes sense, is was this what you had in mind?
>>>>>
>>>>> https://gist.github.com/cynthia/fe95daed5322109f567c
>>>>>
>>>>> (I didn't actually check if this compiles, my work environment is 100%
>>>>> *nix. :-()
>>>>>
>>>>> Cheers,
>>>>> Sangwhan
>>>>>
>>>>> On Thu, Sep 11, 2014 at 10:46 AM, Rick Byers <rbyers@chromium.org>
>>>>> wrote:
>>>>>
>>>>>> Thank you!  Indeed it looks like this is Windows 7 only, and unlike
>>>>>> IE we do still want to support touchscreens on Windows 7 (a small but
>>>>>> non-trivial fraction of our touchscreen users are still on Windows 7).  It
>>>>>> looks like SM_DIGITIZER is false in these cases, so I think we can
>>>>>> try looking at SM_MAXIMUMTOUCHES only when SM_DIGITIZER is true. Sound
>>>>>> reasonable to you?
>>>>>>
>>>>>> Thanks,
>>>>>> Rick
>>>>>>
>>>>>>
>>>>>> On Wed, Sep 10, 2014 at 7:44 PM, Jacob Rossi <
>>>>>> Jacob.Rossi@microsoft.com> wrote:
>>>>>>
>>>>>>>  Definitely happy to help here. Our code is roughly:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> lMaxTouchPoints = 0;
>>>>>>>
>>>>>>> if (Win8+)
>>>>>>>
>>>>>>> {
>>>>>>>
>>>>>>>     lMaxTouchPoints = GetSystemMetrics(SM_MAXIMUMTOUCHES);
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>> return lMaxTouchPoints;
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The OS check is there because we don’t support touch in the IE
>>>>>>> platform on Windows 7 and usage of touchscreen devices on Win7 is extremely
>>>>>>> low (most have moved to Win8+).
>>>>>>>
>>>>>>> Have you seen reports of this on Windows 8/8.1 or just Windows 7?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> There definitely are touchpad drivers that like to install a fake
>>>>>>> touch driver in order to fake zoom gestures (e.g. pinch to zoom). I don’t
>>>>>>> think there’s a way for the Windows input stack to tell the difference
>>>>>>> between that and an actual touchscreen. But if you’d like, I can loop you
>>>>>>> in with our Win32 input team.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -Jacob
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *From:* rbyers@google.com [mailto:rbyers@google.com] *On Behalf Of *Rick
>>>>>>> Byers
>>>>>>> *Sent:* Wednesday, September 10, 2014 10:26 AM
>>>>>>> *To:* Jacob Rossi
>>>>>>> *Cc:* public-pointer-events@w3.org; David Bokan
>>>>>>> *Subject:* IE implementation of navigator.maxTouchPoints
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Hey Jacob,
>>>>>>>
>>>>>>> We're getting reports of some complaints of navigator.maxTouchPoints
>>>>>>> returning 1 on Chrome when there is in fact no touchscreen.  IE11 correctly
>>>>>>> returns 0.  http://crbug.com/352942.  Scott (from MS OpenTech)
>>>>>>> wrote the code
>>>>>>> <https://code.google.com/p/chromium/codesearch#chromium/src/ui/base/touch/touch_device_win.cc&q=MAXTOUCHPOINTS&sq=package:chromium&type=cs&l=17>
>>>>>>> for this for us, basically just:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> int MaxTouchPoints() {
>>>>>>>
>>>>>>>   return GetSystemMetrics(SM_MAXIMUMTOUCHES);
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Apparently, despite what we'd expect fro the MSDN docs, this is
>>>>>>> insufficient.  Users report that it returns 1 in scenarios with both an
>>>>>>> internal and external mouse plugged in - although we haven't been able to
>>>>>>> reproduce it (and they've confirmed they see those values from the API
>>>>>>> directly, so it's not some bug in chrome).
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Any chance you can share the algorithm with us that IE uses to
>>>>>>> compute maxTouchPoints on windows?  Ideally Chrome and IE would always
>>>>>>> agree here, and there's obviously some special cases.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>>    Rick
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Sangwhan Moon [Opera Software ASA]
>>>>> Software Engineer | Tokyo, Japan
>>>>>
>>>>
>>>>
>>>
>>
>
Received on Friday, 12 September 2014 07:00:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:48:10 UTC