Pointer/hover media query support: platform-dependent changes

ui/base/touch/touch_device.h

Index: ui/base/touch/touch_device.h
diff --git a/ui/base/touch/touch_device.h b/ui/base/touch/touch_device.h
index fd75ebcc9c6714e66ae918ab7a276e299d6b9bb9..3ff065a619febafe5a5388b44843a6da09243829 100644
--- a/ui/base/touch/touch_device.h
+++ b/ui/base/touch/touch_device.h
@@ -26,6 +26,28 @@ UI_BASE_EXPORT bool IsTouchDevicePresent();
 // http://www.w3.org/TR/pointerevents/#widl-Navigator-maxTouchPoints
 UI_BASE_EXPORT int MaxTouchPoints();
 
+// Bit field values indicating what kind of pointer types are available. These
+// enum must match content::PointerType enums.
+// GENERATED_JAVA_ENUM_PACKAGE: org.chromium.ui.base
+enum PointerType {
+  PointerTypeNone = 1,

[jdduke (slow), 2014/10/31 15:51:44]

Why start with 1 for None? Also, the typical way of styling bit flags would be:

PointerTypeNone = 0,
PointerTypeCoarse = 1 << 0,
PointerTypeHover = 1 << 1,
etc...

[mustaq, 2014/10/31 16:58:20]

Short answer: I followed the blink-side (WebSettings.h) as is.

Re none=1: bokan@ and I had a discussion about this few days ago. He mentioned
that we wanted to differentiate between unknown vs known-none types. The MQ spec
doesn't distinguish these two possibilities and treats "none" as zero, which
IMHO is not the right thing to do. I would prefer a PointerTypeUnknown==0 on the
spec.

One possibility is to add PointerTypeUnknown=0 enum value in both chromium &
blink, and limit the MQ weirdness in blink::MediaQueryEvauator. wdyt?

Re shifting 1: Yes, this is clearer. Will fix.

[bokan, 2014/11/03 14:28:11]

Actually, this isn't to do with an "unknown" value (the spec doesn't have an
"unknown" option). It's to correctly handle the any-pointer/hover union [1];
none is a property of the pointer, not an absence of pointers. i.e. we can have
any-pointer: none *and* any-pointer: fine both return true if we have two
"pointing" devices, one with a fine precision and one without the ability to
point (maybe a speech based input?)

It's easier to see with hover. If we have a mouse and a touch screen, any-hover
will eval to true for either 'none' or 'hover'. Therefore 'none' can't be 0.

Also, in the spec "none" isn't treated as zero technically, it evaluates to
false in a boolean context [2]. This is to match the CSS style where a media
feature evaluated in a boolean context returns true for non-none, non-0 values.
This makes statements like @media (pointer) intuitive, it will evaluate to true
if there is a pointing capability, regardless of its precision.

WRT an unknown value, I don't think it adds any value. We'd be better off just
making a reasoned guess if we really can't figure out anything about our input
devices. e.g. on Desktop platforms, fall back to pointer: fine hover: hover.

[1] http://dev.w3.org/csswg/mediaqueries-4/#any-input
[2] http://dev.w3.org/csswg/mediaqueries-4/#mq-boolean-context

[mustaq, 2014/11/03 17:11:38]

Thanks for the clarification. Will keep the 1-based enums unchanged.

+  PointerTypeCoarse = 2,
+  PointerTypeFine = 4
+};
+
+// Bit field values indicating what kind of pointer types are available. These
+// enums must match content::HoverType enums.
+enum HoverType {
+  HoverTypeNone = 1,

[jdduke (slow), 2014/10/31 15:51:44]

Why can't we just use the ui::PointerType/ui::HoverType enums in content?

[mustaq, 2014/10/31 16:58:20]

Hmm, didn't think this way. I instead considered using content::HoverTypes here
but it would cause build-rule troubles with generated java enums. Let me get
back to you after I am successful in the java enum front.

+  HoverTypeOnDemand = 2,
+  HoverTypeHover = 4
+};
+
+UI_BASE_EXPORT int AvailablePointerTypes();
+UI_BASE_EXPORT PointerType PrimaryPointerType();
+UI_BASE_EXPORT int AvailableHoverTypes();
+UI_BASE_EXPORT HoverType PrimaryHoverType();
+
 #if defined(OS_ANDROID)
 bool RegisterTouchDeviceAndroid(JNIEnv* env);
 #endif