Now it looks to me this is change in version 62. Once I upgrade to version 62, it repros on Windows and Mac too. Previously I did not see on Windows and Mac probably because I was using version 61.

Able to reproduce this issue on reported version 62.0.3202.62, on latest stable 62.0.3202.75 and on latest canary 64.0.3250.0 using Ubuntu 14.04 with steps mentioned in comment#0.

Note: Issue is not reproducible on Mac 10.12.6 and Win 10

Good build: 60.0.3102.0
Bad build: 60.0.3103.0

CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/5978e88f58a40606f6f2cc6535394feeb1279854..83f1b6d5641a294f5b1fb8d52e37e0a1f9ff08d5

Possible Suspect: https://codereview.chromium.org/2827803002

@alexis.menard: Please confirm the bug and help in re-assigning if it is not related to your change.

I'll have a look early next week.

Ok found the issue. I'll make a patch but I can only test on Thursday, I'm attending TPAC.

Couple of comments here :
- Mac code was never changed and always returns HOVER_TYPE_HOVER only (see https://cs.chromium.org/chromium/src/ui/base/touch/touch_device.cc?sq=package:chromium&l=29)
- The spec was changed not so long ago to clarify the any-hover:none behavior. It turns out that when we made the interaction MQ dynamic we looked at the spec before the clarification. Our interpretation was different at the time and different than what we did previously.

This bug is not a regression but rather an alignment with the spec, see https://github.com/w3c/csswg-drafts/pull/842#issuecomment-343764793

It will require updating our Android, Linux and Windows implementation. I have the patch ready but I need to test it. Probably will upload something end of this week or beginning of this week.

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

commit f0f725522202d8308417d2a0584df01c3107d53a
Author: Alexis Menard <alexis.menard@intel.com>
Date: Mon Dec 04 19:33:22 2017

Align any-hover:none behavior to current specification.

The spec was updated some time ago clarifying how
any-hover: none should match (see
https://github.com/w3c/csswg-drafts/commit/98f494677a265df504eee67d587329478b8ce6ba).
This patch aligns the behavior with the spec clarification
by making sure that 'any-hover:none' will only evaluate to
true if there are no pointing devices, or if all the pointing
devices present lack hover capabilities.

The previous implementation was reading the specification
literally by returning the union of the capabilities of
the input devices connected on the machine.

Windows, Linux and Android are now updated in this patch.

This technically has a compatibility impact as we're changing
behavior but @rbyers and myself did a rapid search of top websites
 and didn't find anything relevant to the change.

BUG= 778694 

Change-Id: I230a44f29707e660515b4d27a1bc88552aa73032
Reviewed-on: https://chromium-review.googlesource.com/803662
Commit-Queue: Alexis Menard <alexis.menard@intel.com>
Reviewed-by: Mustaq Ahmed <mustaq@chromium.org>
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Cr-Commit-Position: refs/heads/master@{#521407}
[modify] https://crrev.com/f0f725522202d8308417d2a0584df01c3107d53a/ui/android/java/src/org/chromium/ui/base/TouchDevice.java
[modify] https://crrev.com/f0f725522202d8308417d2a0584df01c3107d53a/ui/base/touch/touch_device_linux.cc
[modify] https://crrev.com/f0f725522202d8308417d2a0584df01c3107d53a/ui/base/touch/touch_device_win.cc