Full Text Bug Listing

Rick Byers

Reported 2014-07-10 19:02:16 PDT

Chrome and IE will soon be shipping full support for the "interaction media features" from MQ4: http://dev.w3.org/csswg/mediaqueries4/#mf-interaction (Eg. pointer and hover). https://code.google.com/p/chromium/issues/detail?id=136119 We feel these are important to help rationalize touch feature detection (eg. dev tools emulation, touchscreen laptops, etc.) and help correct some of the many false assumptions web developers make when they see that touch events are supported. Any chance WebKit would also be interested in implementing these features? It would probably be OK to trivially hard-code them as follows: on Mac OS X: pointer: fine, hover, any-pointer: fine, any-hover on iOS: pointer: coarse, !hover, any-pointer: coarse, !any-hover Although you may want to do the work to detect whether a mouse is plugged in on Mac OS X to properly differentiate pointer: fine and pointer: none.

Rick Byers

Comment 1 2014-07-21 18:04:47 PDT

*** Bug 87806 has been marked as a duplicate of this bug. ***

Rick Byers

Comment 2 2014-07-21 18:05:05 PDT

*** Bug 88339 has been marked as a duplicate of this bug. ***

Benjamin Poulain

Comment 3 2015-01-22 20:13:34 PST

Created attachment 245199 [details] Patch

WebKit Commit Bot

Comment 4 2015-01-22 20:15:33 PST

Attachment 245199 [details] did not pass style-queue: ERROR: Source/WebCore/css/MediaQueryEvaluator.cpp:668: any_hoverMediaFeatureEval is incorrectly named. Don't use underscores in your identifier names. [readability/naming/underscores] [4] ERROR: Source/WebCore/css/MediaQueryEvaluator.cpp:686: any_pointerMediaFeatureEval is incorrectly named. Don't use underscores in your identifier names. [readability/naming/underscores] [4] Total errors found: 2 in 48 files If any of these errors are false positives, please file a bug against check-webkit-style.

Rick Byers

Comment 5 2015-01-23 13:21:53 PST

Comment on attachment 245199 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=245199&action=review > Source/WebCore/css/MediaQueryEvaluator.cpp:662 > + return hoverCSSKeywordID == CSSValueNone; I think the spec would expect mobile Safari to return true for "on-demand". I.e. long press (last I checked) triggers :hover styles. Personally I don't see a ton of value in differentiating between on-demand and none (wasn't my idea to add that bit to the spec), but that's how we implement it in chromium.

Benjamin Poulain

Comment 6 2015-01-23 13:32:01 PST

(In reply to comment #5) > Comment on attachment 245199 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=245199&action=review > > > Source/WebCore/css/MediaQueryEvaluator.cpp:662 > > + return hoverCSSKeywordID == CSSValueNone; > > I think the spec would expect mobile Safari to return true for "on-demand". > I.e. long press (last I checked) triggers :hover styles. Personally I don't > see a ton of value in differentiating between on-demand and none (wasn't my > idea to add that bit to the spec), but that's how we implement it in > chromium. I understand the idea of "on-demand" for Android but I don't think it is interesting for iOS: 1) Hover is not at all part of the design language of the platform. 2) The "hover" event we support is pure legacy stuff, that is not something you can easily rely on. When given the choice of a stylesheet that relies little to hover or a stylesheet that do not rely at all on hover, iOS should get the later IMHO. Thanks for checking the patch by the way!

Rick Byers

Comment 7 2015-01-23 13:43:32 PST

Comment on attachment 245199 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=245199&action=review >>> Source/WebCore/css/MediaQueryEvaluator.cpp:662 >>> + return hoverCSSKeywordID == CSSValueNone; >> >> I think the spec would expect mobile Safari to return true for "on-demand". I.e. long press (last I checked) triggers :hover styles. Personally I don't see a ton of value in differentiating between on-demand and none (wasn't my idea to add that bit to the spec), but that's how we implement it in chromium. > > I understand the idea of "on-demand" for Android but I don't think it is interesting for iOS: > 1) Hover is not at all part of the design language of the platform. > 2) The "hover" event we support is pure legacy stuff, that is not something you can easily rely on. > > When given the choice of a stylesheet that relies little to hover or a stylesheet that do not rely at all on hover, iOS should get the later IMHO. > > Thanks for checking the patch by the way! Interesting. I'm not sure Android is any different in this regard - I agree we'd always prefer a stylesheet that doesn't rely on hover (except on devices like the Galaxy S4 which have a hover-sensitive touchscreen, should we decide to expose that to the web platform). If you think 'none' is the better value for mobile Safari, perhaps we should change Chrome android to match? Are you interested in starting a discussion with CSSWG around this? I don't think I was part of the discussion where on-demand was added (or at least I didn't pay enough attention). > Thanks for checking the patch by the way! You bet, I believe this is my old code that you're cleaning up (sorry) <grin>. Thanks for adding this to Safari even though it doesn't communicate any new information!

Benjamin Poulain

Comment 8 2015-01-23 14:28:45 PST

(In reply to comment #7) > >> I think the spec would expect mobile Safari to return true for "on-demand". I.e. long press (last I checked) triggers :hover styles. Personally I don't see a ton of value in differentiating between on-demand and none (wasn't my idea to add that bit to the spec), but that's how we implement it in chromium. > > > > I understand the idea of "on-demand" for Android but I don't think it is interesting for iOS: > > 1) Hover is not at all part of the design language of the platform. > > 2) The "hover" event we support is pure legacy stuff, that is not something you can easily rely on. > > > > When given the choice of a stylesheet that relies little to hover or a stylesheet that do not rely at all on hover, iOS should get the later IMHO. > > > > Thanks for checking the patch by the way! > > Interesting. I'm not sure Android is any different in this regard - I agree > we'd always prefer a stylesheet that doesn't rely on hover (except on > devices like the Galaxy S4 which have a hover-sensitive touchscreen, should > we decide to expose that to the web platform). If you think 'none' is the > better value for mobile Safari, perhaps we should change Chrome android to > match? Are you interested in starting a discussion with CSSWG around this? > I don't think I was part of the discussion where on-demand was added (or at > least I didn't pay enough attention). I am already in the CSS WG if you want to start a thread. I am not sure there is any need to spec here. It seems more like a policy problem.

Benjamin Poulain

Comment 9 2015-01-23 20:15:59 PST

Comment on attachment 245199 [details] Patch Clearing flags on attachment: 245199 Committed r179055: <http://trac.webkit.org/changeset/179055>

Benjamin Poulain

Comment 10 2015-01-23 20:16:04 PST

All reviewed patches have been landed. Closing bug.

Alexey Proskuryakov

Comment 11 2015-01-23 21:27:35 PST

This broke Mac build: /Volumes/Data/slave/yosemite-release/build/WebKitBuild/Release/DerivedSources/WebCore/JSInternalSettingsGenerated.cpp:1061:10: error: no member named 'setDeviceSupportsMouse' in 'WebCore::InternalSettingsGenerated' impl.setDeviceSupportsMouse(deviceSupportsMouse); ~~~~ ^ /Volumes/Data/slave/yosemite-release/build/WebKitBuild/Release/DerivedSources/WebCore/JSInternalSettingsGenerated.cpp:1078:10: error: no member named 'setDeviceSupportsTouch' in 'WebCore::InternalSettingsGenerated' impl.setDeviceSupportsTouch(deviceSupportsTouch); ~~~~ ^ 2 errors generated. Surprised that EWS didn't say so, were there additional changes landed?

hexalys

Comment 12 2015-07-15 00:05:49 PDT

(In reply to comment #8) > I am not sure there is any need to spec here. It seems more like a policy > problem. Any-hover:none seems ok. But I am looking at the iOS Simulator where it should technically be 'pointer: fine'. It's coarse ATM. That'll help making the distinction between a simulator or touch emulation and the actual device with a touch screen.

Benjamin Poulain

Comment 13 2015-07-15 00:07:41 PDT

(In reply to comment #12) > (In reply to comment #8) > > > I am not sure there is any need to spec here. It seems more like a policy > > problem. > > Any-hover:none seems ok. But I am looking at the iOS Simulator where it > should technically be 'pointer: fine'. It's coarse ATM. That'll help making > the distinction between a simulator or touch emulation and the actual device > with a touch screen. That is intended. The simulator is supposed to behave like the device as much as possible.

hexalys

Comment 14 2015-07-15 00:32:20 PDT

(In reply to comment #13) > > Any-hover:none seems ok. But I am looking at the iOS Simulator where it > > should technically be 'pointer: fine'. > > That is intended. The simulator is supposed to behave like the device as > much as possible. Ok, fair enough. But the problem is, it's so identical that it can't be detected anymore. I'd welcome a return of 'Emulator' in the UA or navigator.platform as it was in iOS 5 phone simulator. There are valid reasons to exclude simulator visits from analytics (e.g. not to pollute google analytics performance stats) or identify them as debug mode, etc...

Benjamin Poulain

Comment 15 2015-07-15 00:36:24 PDT

(In reply to comment #14) > (In reply to comment #13) > > > Any-hover:none seems ok. But I am looking at the iOS Simulator where it > > > should technically be 'pointer: fine'. > > > > That is intended. The simulator is supposed to behave like the device as > > much as possible. > > Ok, fair enough. But the problem is, it's so identical that it can't be > detected anymore. I'd welcome a return of 'Emulator' in the UA or > navigator.platform as it was in iOS 5 phone simulator. There are valid > reasons to exclude simulator visits from analytics (e.g. not to pollute > google analytics performance stats) or identify them as debug mode, etc... We used to get quite a bit of complain when the user-agent was saying it is the emulator. Some websites could not be tested properly because they relied on user-agent sniffing. Can the iOS emulator really be a problem for analytics? There are several thousands iOS developers against several millions iOS users. At worst that is a drop in the ocean.

hexalys

Comment 16 2015-07-15 01:39:56 PDT

(In reply to comment #15) > We used to get quite a bit of complain when the user-agent was saying it is > the emulator. Some websites could not be tested properly because they relied > on user-agent sniffing. Ok. Odd complaint for not doing it right. But I could see how it somehow affected their readings. > Can the iOS emulator really be a problem for analytics? There are several > thousands iOS developers against several millions iOS users. At worst that > is a drop in the ocean. Not a deal breaker in terms of performance data. But for a small site that has less then 30 visits a days, with a Dev or any other person doing 10+ visits a day, it can affect metrics significantly over short periods of time, yes. One method is via Device Orientation readings at load which is not exactly ideal... I am setting debug cookies for scripts anyway. I was just looking for a better detection method.

Raphael Schweikert

Comment 17 2020-12-10 08:25:18 PST

It seems that iPadOS with an attached pointing device will still report none for the pointer and hover media queries. Any chance of this being fixed?

Attachments
Patch (68.99 KB, patch) 2015-01-22 20:13 PST, Benjamin Poulain	no flags	Details Formatted Diff Diff
View All Add attachment proposed patch, testcase, etc.

Bug 134822