Consider using @media(pointer) query instead of tablet mode for command buttons
Categories
(Firefox :: Theme, task)
Tracking
()
People
(Reporter: cmartin, Unassigned)
References
Details
In Bug 1164675, special code was added to apply a "tabletmode" attribute to the root element when Windows 10 Tablet Mode is enabled, and to cause the minimize and maximize/restore buttons to disappear.
Perhaps that is still the best solution, but modern CSS has the "@media (pointer: coarse)" query that is meant to be used to detect if your user is on a touch screen (coarse pointing device) or is using a mouse (fine pointing device).
On top of being a standard, using this instead would ensure that the Firefox chrome behaves the same way web pages behave when they rely on media queries, and it would allow us to remove this 'special path' from our code.
(It's also possible that I don't understand things and this behavior is desired for Windows 10 Tablet Mode exclusively -- If that's the case, feel free to dismiss the ticket)
|
||
Comment 1•4 years ago
|
||
On Windows 10, "tablet mode" is a special mode of Windows where there are no restored or minimized windows, only fullscreen ones and a topmost one, which is why the other icons get removed. See e.g. https://support.microsoft.com/en-us/windows/use-your-pc-like-a-tablet-4fbfcca5-f058-814a-4f80-a12e703d7c34
This is orthogonal to whether it's a touch device - you can use a touch-enabled device without enabling tablet mode, and I don't think Windows will prompt to enable it unless you detach all keyboard input or make another hardware change (e.g. with the yoga laptops you can flip the keyboard 360 degrees so it's inaccessible, behind the screen) that signifies you want to use the machine as a tablet, without keyboard input.
So I don't think connecting this to the pointer: coarse media query would be correct. Does that explanation makes sense?
|
|
||
Comment 2•4 years ago
|
||
(We have other frontend support for touch devices that might benefit from this new media query if we implement it, though I'm curious whether the media query applies if the user has both a mouse and a touch device...)
|
Reporter | |
Comment 3•4 years ago
|
||
Ah, so this is a behavior that is specific to "Windows 10 Tablet Mode" and not something that you would want to happen if the user was using any device as a tablet (for instance, if the user unplugged all keyboards and mice from a device with a touchscreen)
If that's the case, then what is already there is probably as good as it gets (short of us changing it over to be a non-standard media query)
(In reply to :Gijs (he/him) from comment #2)
(We have other frontend support for touch devices that might benefit from this new media query if we implement it, though I'm curious whether the media query applies if the user has both a mouse and a touch device...)
To elaborate, there are 2 queries: @media (pointer) and @media (any-pointer)
The logic for the first is more-or-less:
- Is the computer in Windows 10 Tablet Mode: Coarse
- If not, is the device an undocked touchscreen device that the OEM considers a tablet: Coarse
- If not, does the device have a mouse plugged into it: Fine
- If not, does it have an external "digitizer" attached to it: Coarse
- If not, there is no pointing device: None
The logic for the second is the logical-OR of the above. So if there is both a touchscreen and a mouse, both @media (any-pointer: fine) and @media (any-pointer: coarse) will be true.
I don't know if that changes anything for you at all, but if you want we can just close this bug. It sounds like the behavior you want is "Windows 10 Tablet Mode" specific.
|
|
||
Comment 4•4 years ago
|
||
Yes, I think for the specific case of the minimize/maximize/restore buttons, this is currently correct. The main other thing I was thinking of was touch density in menus, but that currently depends on the event that opens the menu - if it is a touch event (or even a click/mouse event that was simulated as a result of a touch interaction), the menu gets touch density. That too is probably better than always doing the same for a device that has touch support. I'm not sure if there are other Firefox frontend UI bits where we'd benefit from switching to this media query, but I'll definitely keep it in mind going forward!
Description
•