2005506 - RFP: check android pointer/hover protections

Status: NEW

(Core :: Layout, enhancement)

Description

[Thorin [:thorin]]

Archaeology: Bug 1607316 | Other: Bug 1363508, Bug 1826051, Bug 1957658

This is not an area I am familiar with TBH, but I'll try my best. In Bug 1607316 (FF74) we spoofed the set of pointer, any-pointer, hover, any-hover differently to desktop. We've also had changes over time with, e.g. recently (Bug 1957658?) no longer bothering to try and hide touch on desktop (linux/mac) because it's impossible and also big deal (cuz we made all desktop look touch capable) - but I'm not sure if any of that code or what any previous code did re android.

Which brings us to the current state of affairs. If you use https://arkenfox.github.io/TZP/tzp.html#css (the CSS section) and expand the media result you can see the four properties: two results each: one from css and one from matchmedia. Note each any-pointer test has two tests because the order matters - spec is at https://www.w3.org/TR/mediaqueries-4/#any-input

In the case of any-pointer, more than one of the values can match, if different pointing devices have different characteristics

here are some android results (Samsung galaxy 2S4 FE)

            phone                tablet [1]
chrome                           tablet [2]
    any-hover: hover
        hover: hover
  any-pointer: fine + coarse
      pointer: coarse

FF (no RFP)
    any-hover: hover              hover
        hover: none               none
  any-pointer: fine + coarse      fine + coarse
      pointer: coarse             coarse

FF+RFP and TB (all as designed, green ticks)
    any-hover: none
        hover: none
  any-pointer: coarse + coarse
      pointer: coarse

[1] Galaxy S11 Ultra with and without a cover-keyboard (does not have a touch pad)
[2] paired with a Bluetooth mouse

If the only thing we're trying to mask on android now is when a pen is used, then I don't understand why the above RFP is so adversarial (i.e not real world). IDK if these values can change based on connected devices (e.g. I have a samsung galaxy lastest model tablet with a keyboard/stand thing but haven't tested) so we obviously want to make sure out values are consistent - but AFAICT we don't need to enforce all hover as none and all pointer as coarse - to me that's a red flag that will one day be used against us

I'll defer to pier since he's been doing a number of touch/pointer patches recently

Comment 1

[Thorin [:thorin]]

updated comment0 - tested my tablet with and without a keyboard and a bluetooth mouse - no change - so unless I'm missing something, a generic FP of these values (i.e not testing real-time usage) could have better hardcoded RFP values

Comment 2

[Pier Angelo Vendrame]

I think this needs more investigation.
I get any-pointer: coarse + coarse on my phone (on both Chrome and Firefox stable no RFP), but it's very old at this point.
As for hover, I get hover on Firefox, and none on Chrome. So, we're actually not completely malign, but I'd have to investigate on the code, to check if Firefox ever returns none for hover on Android. If it doesn't, RFP should align to non-RFP.

Comment 3

[Thorin [:thorin]]

but it's very old at this point

that makes sense .. old hardware, so not totally adversarial for *pointer. So I liken this to touch on desktop (linux/windows), we report modern hardware if that's the right term (fine + coarse) and then when someone uses fine (which AFAICT we can't hide [1]) it's not a surprise - and those that can't use fine never use it so nothing lost.

As for hover, I get hover on Firefox, and none on Chrome

Same as comment0 - I would be interested as to why chrome is different and who's not following the spec

[1] we can review mouse/pen on android (and pen on desktop) in another issue