1980472 - RFP: maxTouchPoints mismatches with window Touch properties

Status: RESOLVED INVALID

(Core :: DOM: Events, enhancement)

Description

[Thorin [:thorin]]

After Bug 1957658 we now have with RFP and maxTouchPoints (correct me I'm wrong, thanks - Tor Browser I assume will backport or ask for a backport)

• android: 5
• windows: 10
• mac + linux: 0

There is also a pref, dom.w3c_touch_events.enabled 0=disabled (macOS) 1=enabled 2=autodetect (linux/win/android) - I think the prefs are as I've just written, the notes are from a year ago. Android is fine (always has touch), mac is fine (no such thing, yet)

With autodetect: on android this adds a number of ontouch* properties (window, element), but not desktop, as these properties cause compat issues with websites arbitrarily deciding this means you are mobile. But the other thing this does, is also add some element window Touch* properties, which are fingerprintable. So with windows, my touch capable laptop has these values, but my non-touch desktop rig doesn't - and reporting 10 maxTouchPoints without those properties is a mismatch, not to mention we are creating entropy that doesn't need to exist. For linux I am not sure what happens - IIUIC touch requires a startup command - but it shouldn't matter since we can control it all.

The pref can be toggled and does not require a restart, so it should work with RFPTargets and exemptions.

Here's a code snippet (edit: the hashes are what I would expect when we fix this)

let rfpHashes = {
	'android': 'c8ec70b1',
		/*
		{	"element": ["ontouchstart", "ontouchend", "ontouchmove", "ontouchcancel"],
			"maxTouchPoints": 5,
			"window": ["TouchEvent","TouchList","Touch","ontouchstart","ontouchend","ontouchmove","ontouchcancel"]
		}
		*/
	'linux': 'd539fa63', // {"element": "none", "maxTouchPoints": 0, "window": "none"}
	'mac': 'd539fa63',
	'windows': '14bcf9db', // {"element": "none", "maxTouchPoints": 10, "window": ["TouchEvent", "TouchList", "Touch"]}
}

These are real-world benign values that don't break expected gecko behavior.

ToDo

• windows: enforce dom.w3c_touch_events.enabled as 1
• linux: enforce dom.w3c_touch_events.enabled as 0
• Tor Browser can just enforce these prefs since they don't use RFPTargets

Comment 1

[Thorin [:thorin]]

Attachment: non-touch windows.png

here's my non-touch desktop with the mismatch code logic (local, not live) - the result differs from my laptop with RFP

Comment 2

[Fatih Kilic [:fkilic]]

By mismatch are you saying windows is 10 and android is 5? I did that way based on this comment https://bugzilla.mozilla.org/show_bug.cgi?id=1957658#c8. About the pref, we disable auto detection and enable events if spoofed max touch points is >= 1.

Comment 3

[Thorin [:thorin]]

Attachment: this.png

(In reply to Fatih Kilic [:fkilic] from comment #2)

By mismatch are you saying windows is 10 and android is 5?

No. We don't care about OS diffs and never have. The mismatch is that a desktop machine that has touch (for real, like my windows touch laptop) also has some Touch* window properties - these are missing when we return maxTouchPoints > 0 and the desktop machine doesn't have touch (for real, like my windows desktop rig)

// a real windows machine without RFP: element and window refer to properties of those
    // ^ my windows laptop actually has maxTouchPoints = 10
    // dom.w3c_touch_events.enabled = 2 (autodetect) and because my laptop actually has touch, there are three window Touch* properties
{"element": "none", "maxTouchPoints": 10, "window": ["TouchEvent", "TouchList", "Touch"]}

// RFP on my laptop: it just happens to match my non-RFP values
{"element": "none", "maxTouchPoints": 10, "window": ["TouchEvent", "TouchList", "Touch"]}

// RFP on my desktop rig
    // dom.w3c_touch_events.enabled = 2 (autodetect) and because my desktop actually has NO touch, there are NO Touch* properties
{"element": "none", "maxTouchPoints": 10, "window": "none"}

that's the mismatch - we're not controlling the window Touch properties

Comment 4

[Fatih Kilic [:fkilic]]

Interesting, I can't reproduce. I get the Touch* props (I'm on OSX so I manually set dom.w3c_touch_events.enabled = 2 and set this line to enabled = true;)

Comment 5

[Thorin [:thorin]]

I don't understand. You shouldn't have Touch properties on mac and dom.w3c_touch_events.enabled = 2 means autodetect and mac has none. As per OP, this affects linux and windows

Comment 6

[Fatih Kilic [:fkilic]]

Yeah that's why said

I manually ... set this line to enabled = true;

On windows, that line will evaluate to true, so I just set it to true in an effort to reproduce the issue.

Comment 7

[Pier Angelo Vendrame]

I confirm that dom.w3c_touch_events.enabled set to 2 is leaky also for me.

Comment 8

[Fatih Kilic [:fkilic]]

Hmm on my desktop windows machine (which doesn't have any touch support) with RFP I get Touch* and without RFP I don't get them. Are you all refreshing the page after setting RFP on and off?

Comment 9

[Pier Angelo Vendrame]

IIRC this is one of the cases in which you need to restart the browser

Comment 10

[Fatih Kilic [:fkilic]]

For me refreshing the page worked, but I that should work too

Comment 11

[Thorin [:thorin]]

(In reply to Thorin [:thorin] from comment #0)

The pref can be toggled and does not require a restart, so it should work with RFPTargets and exemptions.

you don't need to restart

Comment 12

[Thorin [:thorin]]

(In reply to Fatih Kilic [:fkilic] from comment #4)

Interesting, I can't reproduce

I noticed this now "seems" fixed (FF143) - in real time you can toggle RFP and retest and it works flawlessly - so would have or could have been some patch gated behind or landed in nightly and then rode the train - maybe for simulations IDK. Will investigate via moz-regression. We would actually want this behavior behind RFP to be robust

Comment 13

[Thorin [:thorin]]

Ok, my bad - moz-regression points to

• Bug 1957658 - Set max touch points as discussed. Disable automatic touch support detection if we are RFPing. r=tjr

I must have tested the wrong build and/or made some assumptions .. going to my corner :)