Closed Bug 1747633 Opened 3 years ago Closed 3 years ago

CSS Media Queries for Interaction do not work

Categories

(Core :: Widget: Win32, defect)

Product:
Core
Component:
Widget: Win32
Version:
Firefox 95
Type:
defect

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: mozilla, Unassigned)

References

Details

Attachments

(1 file)

Test-case from reporter
231 bytes, text/html
Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:95.0) Gecko/20100101 Firefox/95.0

Steps to reproduce:

Trying to use any-hover, any-pointer, hover or pointer does not provide the proper styling in Firefox. Example:

@media (any-hover: none) {
  body { background: yellow; }
}
@media (any-hover: hover) {
  body { color: red; }
}
@media (any-pointer: fine) {
  body { background: blue; }
}

The System only has Keyboard and Mouse attached as input devices.

Actual results:

The background property is set to yellow. Firefox appears to ignore currently connected input devices entirely.

Expected results:

The background property should be set to blue, and the color property should be set to red. This is what is seen in Chrome, Edge, Opera and Safari.

The Bugbug bot thinks this bug should belong to the 'Core::CSS Parsing and Computation' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → CSS Parsing and Computation
Product: Firefox → Core

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:95.0) Gecko/20100101 Firefox/95.0

Tested on several devices now. On some it works as expected, on others any-pointer: fine is active but they don't have anything but touch inputs (no pointers), and on others it shows the above described behavior. In every single case, Chrome, Edge and Opera behave the same and correctly.

You're seeing this on windows, right? And to be clear, does it repro on a clean profile?

https://searchfox.org/mozilla-central/rev/42c90d1426f244db74a164a3121e164f601ad439/widget/windows/WinUtils.cpp#1964 is the relevant code, I'd be curious to know what's going on on those devices, generally the code there seems sane.

More information on the specific device where this happens would be useful.

Component: CSS Parsing and Computation → Widget: Win32

Seems to work fine on my machine unfortunately, so yeah we probably need some more information on what kind of device are you using.

See Also: → 1638556

Relevant chromium code is here: https://source.chromium.org/chromium/chromium/src/+/main:ui/base/pointer/pointer_device_win.cc;l=42;drc=8586102b48a409c634250f31c3fc7bdde5ec3db0

It seems we get wrong some cases that Chrome gets right, and vice versa... Hiro, thoughts?

Flags: needinfo?(hikezoe.birchill)

Yes, I've reproduced this with as clean a profile as Firefox allows me to create. All of the test were on Windows 10 21H2, though the build number differs between systems. Here's a list of system I tested extensively:

  1. Windows 10 Pro 21H2 19044.1415: Mouse, Keyboard, Gamepad (Bluetooth), MIDI-Keyboard
  2. Windows 10 Pro 21H2 19044.1288: Trackpad, Keyboard, Gamepad (Bluetooth)
  3. Windows 10 Pro 21H1 19043.1151: Touch only
  4. Windows 10 Pro 20H2 19042.1202: Touch, Mouse (Bluetooth), Keyboard (Bluetooth)

Here's the behavior on each device:

  1. Behavior changes if Firefox is restarted. Sometimes Expected Result, sometimes Actual Result.
  2. Behavior is the Expected Result.
  3. Incorrectly claims (any-)pointer: fine.
  4. Behavior changes if Firefox is restarted. Sometimes Expected Result, sometimes Actual Result.

All four devices work correctly in the other "three" Browsers, not changing in behavior. Windows itself seems to have no problems figuring out the actual input method used at any point in time.

Sorry, I meant to say "all of the tests were on Windows 10", not with a specific version after it. Started reading winver output in the middle of writing that and confused myself. I couldn't find anything in common between the systems, so here is their hardware and software information:

  1. AMD X570 Chipset, AMD Ryzen Zen 3, 64GB RAM, Firefox 95.0.2 (64-bit)
  2. Intel Chipset, Intel i7-7700HQ, 16GB RAM, Firefox 95.02 (64-bit), (Fresh Windows + Firefox install)
  3. AMD X570 Chipset, AMD Ryzen Zen 1, 32GB RAM, Firefox 95.0.2 (64-bit)
  4. AMD Chipset (Unknown), AMD Ryzen Zen 3 Mobile, 16GB RAM, Firefox 95.0.2 (64-bit), (Fresh Windows + Firefox install)

Michael, thanks for the bug report. Can you please try mozgression to see whether it's a regression or not? If this is a regression, I'd bet bug 1493128 is the culprit (and if it is, I have no idea to solve this situation). Thanks!

Flags: needinfo?(hikezoe.birchill) → needinfo?(mozilla)

I'm unable to reproduce the bug anymore since yesterday, though I do not know why. Perhaps Windows updated in secret while I wasn't there, and that somehow fixed something that was interacting with Firefox in a bad way, or perhaps I somehow managed to have two devices within range of a strange self-registering Bluetooth device the last few weeks. Whatever it was, it's magically fixed itself with no changes from my side at all.

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Flags: needinfo?(mozilla)
Resolution: --- → INVALID

Accidentally reproduced this 8 months later, on a machine with no over-the-air device support. Below are two example images, one with Chromium and one with Firefox Nightly:

As the conditions are mostly unknown, here's information about the machine:

And some other Information:

(In reply to Michael Dirks from comment #11)

As the conditions are mostly unknown, here's information about the machine:

  • No actual input devices, purely controlled via remote desktop and KVM software.

I wonder Windows provides any APIs to tell the type of the remote device? I guess Chrome just always reports a mouse? If the remote desktop client device has only touch screen, does Chrome report it correctly?

(In reply to Hiroyuki Ikezoe (:hiro) from comment #12)

I wonder Windows provides any APIs to tell the type of the remote device? I guess Chrome just always reports a mouse? If the remote desktop client device has only touch screen, does Chrome report it correctly?

As the KVM software and Remote Desktop software don't register input devices, but instead insert Keyboard and Mouse events into the Raw input event queue, it would be difficult to even check what devices are present. I think Chromium may be changing the input type based on what is currently being used, and falling back to Mouse+Keyboard if it can't find anything, but I also have no way to check that either (no reattachable touch input devices).

Had some time to look into this further. It appears as if Firefox is only looking at attached input devices, and not available/currently-used input devices. As soon as you attach a certain device to the computer, Firefox switches to match that device's input layout. Which means that as soon as I attached a Mouse, Firefox matched Chromium again. Unfortunately this only lasted until I simulated a touch device, where Firefox was now claiming a normal mouse was a touch input, while Chromium switched between the two based on what was currently used.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: