On a laptop with a similar configuration (Chrome 59.0.3071.115, Win 10.0.14393) but does not have a touchscreen, any-hover and any-pointer return values consistent with the spec (eg. (any-pointer: fine) returns true, (any-hover: hover) returns true, as do (pointer: fine) and (hover: hover)).

Disabling the touchscreen driver on the laptop described in the original issue results in interaction media queries returning the expected values (eg. (any-pointer: fine) will return true with the touchscreen disabled, false with the touchscreen enabled).

The issue is happening on multiple devices with the configuration in the original issue description.

I remembered I had a fairly recent version of Opera (45.0.2552.888) installed on this touchscreen laptop, where media queries returned the correct results. After updating to 46.0.2597.39, it fails identically to Chrome 59.0.3071.115.

Able to reproduce on Windows-10 (Dell precision M3800 touch HIDpi) using chrome latest stable M59-59.0.3071.115  .

Bisect Information:
=====================
Good build: 59.0.3044.0 
Bad Build : 59.0.3046.0 

You are probably looking for a change made after 457848 (known good), but no later than 457867 (first known bad).

Change Log URL: 
----------------https://chromium.googlesource.com/chromium/src/+log/6f7dd6b21b0aa119cc9415a1b714bb106646a066..32133318763d82abf62bea930c40996edbee0671

From the above change log suspecting below change
https://chromium.googlesource.com/chromium/src/+/7b5e4e437bb223e9fd68f749f7b3325356719180
Review URL: https://codereview.chromium.org/2737123003

alexis.menard@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Thanks!

https://chromium.googlesource.com/chromium/src/+/7b5e4e437bb223e9fd68f749f7b3325356719180%5E%21/#F1 is probably the problem.

I'm looking at it right now.

So I managed to get hold on a similar hardware and indeed I can reproduce the problem.

I tracked it down to the fact that GetSystemMetrics(SM_CONVERTIBLESLATEMODE) doesn't return the right thing. We started using with https://chromium.googlesource.com/chromium/src/+/7b5e4e437bb223e9fd68f749f7b3325356719180%5E%21/#F1 so that explains the regression.

On a laptop with a touch screen but without the possibility to enter in tablet mode (such as detachable or convertible) GetSystemMetrics(SM_CONVERTIBLESLATEMODE) always returns that it's in slate mode which makes the input quality detection buggy. I strongly think it's a bug in Microsoft API.

While I was looking at an alternative I saw that touchscreen laptops which are not convertible or detachable doesn't have the ConvertibleSlateMode registry entry (most likely because it never changes value). So does my desktop PC.

@apalaniuk : could you confirm my observation by going into regedit, then HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\PriorityControl and check out if you have a ConvertibleSlateMode entry alongside the rest (such as Win32PrioritySeparation)

A proposed fix would be https://gist.github.com/darktears/fabf290097ee2d7c80512bed0010deaf

@ananta : what do you think? Of course as-is the patch can be improved considering the code below it but I'd like your opinion since you wrote the code originally.

Hi Alexis - 

On my Dell Precision M3800, Win 10.0.14393.1066, key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\PriorityControl does have a ConvertibleSlateMode entry with value 0.

Thanks for looking at this and let me know any other information you need.

@apalaniuk : does the laptop support screen rotation. I believe no since it's not a convertible/detachable/tablet. Please confirm you don't see an icon in the quick actions part in the notification center.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6edbb267b6d43303d08e758ff63f941df5c8ff7f

commit 6edbb267b6d43303d08e758ff63f941df5c8ff7f
Author: Alexis Menard <alexis.menard@intel.com>
Date: Thu Jul 13 19:43:45 2017

[Windows] Fix interactions media queries returning wrong values on some hardware.

Interactions media queries were returning wrong values on laptops with
touch screens which are neither convertible, neither detachable.
The reason is that GetSystemMetrics(SM_CONVERTIBLESLATEMODE) returns
always 0 on these machines which is buggy as they are not in a
slate/tablet mode.

One solution would be to check the presence of ConvertibleSlateMode
key in the registry (that key is used to know when the
laptop is flipped or detached) but it doesn't seem to be consistent
across hardware (my desktop PC doesn't have that key but the hardware
listed in the bug below has it).

The last possible alternative is to query the hardware about screen
rotation. If the screen rotation is supported then it's most likely
a tablet/detachable/convertible, if not then it's a desktop PC, a
non touch laptop or a classic touch laptop. If the screen rotation
is not supported, if the laptop doesn't have a screen rotation sensor
or if the laptop is in laptop mode then it's not a tablet.

BUG= 739430 ,  442418 

Change-Id: I1aad26d7d833a425981bf0d46a7dae9878f19cd1
Reviewed-on: https://chromium-review.googlesource.com/566567
Reviewed-by: Ananta Iyengar <ananta@chromium.org>
Reviewed-by: Carlos Pizano <cpu@chromium.org>
Commit-Queue: Alexis Menard <alexis.menard@intel.com>
Cr-Commit-Position: refs/heads/master@{#486458}
[modify] https://crrev.com/6edbb267b6d43303d08e758ff63f941df5c8ff7f/base/win/win_util.cc

@apalaniuk : can you try Chrome Canary tomorrow or in 2 days to verify the fix?

Verified this issue on Windows-10 using chrome latest dev #61.0.3159.5 by following steps mentioned in the original comment. Observed all the media queries passed except "any pointer:none". Confirming the above fix is working as intended and marking it as TE-Verified for M-61.

Deleted: 739430.PNG 39.6 KB

	739430.PNG 39.6 KB View Download

Anything else I should do on my end? Can the bug be closed?

It would be nice to have confirmation from the reporter that their scenario is indeed fixed in latest Canary, but regardless it seems clear you fixed some cases here so yes we should call it 'Fixed' (and actually already 'Verified' in #c11).  Of course if new/different incorrect cases are discovered, they should be tracked in new bugs.

Thanks for driving this Alexis!  I know this is frustrating when we can't seem to rely on the underlying OS to tell us what we need to know.

No problem, I'll be watching apalaniuk@gmail.com if he answers one day.

Thanks for looking into this - I should be able to rest later today.

*test - tested with 62.0.3179.0 with results identical to #11, so looks resolved to me.

Thanks for the prompt resolution.