[Webkit-unassigned] [Bug 139681] Touch support is reported even when the device doesn't have a touch screen

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Aug 25 09:38:37 PDT 2017


https://bugs.webkit.org/show_bug.cgi?id=139681

--- Comment #15 from Michael Catanzaro <mcatanzaro at igalia.com> ---
(In reply to Michael Catanzaro from comment #13)
> Comment on attachment 243496 [details]
> Patch
> 
> Darin has several reservations about supporting runtime-enabled events, and
> it seems this patch is unlikely to fix websites in practice, correct? I
> think this requires at least discussion on webkit-dev, and possibly with W3C
> and other browsers.

My understanding is that this situation has changed in the past year, and Apple now wants to support runtime-enabled events. (Darin, is this true?) So I think it's fine for us to do this now.

> If we are going to enable touch events at runtime, we should at least try to
> match the behavior of other engines. I am not sure, but I strongly suspect
> other engines are not checking whether the device uses a touchscreen, else
> the broken jQuery that makes a binary choice between using touch events or
> mouse events would not exist. Perhaps for compatibility, we should not be
> checking for whether a touchscreen is present, but for whether a non-touch
> input devices exist. E.g. if a mouse is plugged into your touchscreen
> computer, it's more important for the mouse to work than for the touchscreen
> to work.

This is still seems very important to change.

(In reply to David Gasperoni from comment #14)
> I was wondering if `'ontouchstart' in document.documentElement` should
> return true when in Responsive Design Mode. It would make sure many
> libraries (including Boostrap 3) are going to behave like on mobile Safari.
> 
> I was trying to debug a situation where a `.dropdown-backdrop` had higher
> z-index than `.dropdown-menu` (my fault) and I couldn't reproduce it in
> Safari (neither 10.1.2 or TP 38) while I could in Firefox 56.0b5. In
> Firefox's responsive mode, `'ontouchstart' in document.documentElement`
> return true when the page is loaded with a touch-enabled profile.
> 
> Maybe that would be an interesting proposition.

I honestly have no idea what this means. Responsive Design Mode is a Safari developer option, right? Safari does not have to simultaneously support both touchscreen devices and traditional input devices due to Apple's decision not to manufacture touchscreen laptops, so I don't think Safari's behavior is at all relevant here. Currently ontouchstart always returns true if touch events are enabled at build time (so true on iOS, false on macOS, true for GTK+). The patch here would change it to return true only if touch events are supported by the user's monitor at runtime. My proposal is to change it to return true only if the user does not have a mouse or other pointer input device attached at runtime.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170825/a67c38bc/attachment-0001.html>


More information about the webkit-unassigned mailing list