Think about enabling pointer events again in Tor Browser based on esr78
In legacy/trac#25794 (moved) we disabled pointer events for the time being as parts of Mozilla's defense were not ready yet and/or were largish backports.
We should think about switching to Mozilla's defense and enabling pointer events again where they are enabled by a default Firefox.
Activity
added component::applications/tor browser in Legacy / Trac ff78-esr in Legacy / Trac owner::tbb-team in Legacy / Trac priority::medium in Legacy / Trac severity::normal in Legacy / Trac sponsor::44-can in Legacy / Trac status::new in Legacy / Trac tbb-fingerprinting in Legacy / Trac type::defect in Legacy / Trac labels
FYI: upstream: https://bugzilla.mozilla.org/1363508 FF64+ RFP spoof/suppress Pointer Events https://bugzilla.mozilla.org/1492766 FF65+ RFP pointerEvent.pointerid
Replying to Thorin:
FYI: upstream: https://bugzilla.mozilla.org/1363508 FF64+ RFP spoof/suppress Pointer Events https://bugzilla.mozilla.org/1492766 FF65+ RFP pointerEvent.pointerid
Mobile got Pointer Events support in GeckoView based on mozilla70 and we don't have a defense against that yet. Thus, we should leave them disabled for now so that nothing falls through the cracks here, in particular once we switch to Fenix and revisit the decision later on.
Trac:
Keywords: ff68-esr deleted, ff78-esr addedmentioned in issue legacy/trac#33577 (moved)
moved from legacy/trac#28729 (moved)
added Bug label and removed 1 deleted label
added Fingerprinting label and removed 1 deleted label
removed milestone %Tor Browser: 10.0
I encountered a problem caused by the removal of pointer events while writing a web app. Here is a demo page. It works (you can draw with the mouse) in Firefox 78, and does not work in Tor Browser 10.5.6.
https://people.torproject.org/~dcf/pointerevents.html
I think the logic behind disabling pointer events was that anything that would result in a pointer event will also send a mouse event anyway, so applications written to expect mouse events will not be affected if pointer events are removed.
https://bugzilla.mozilla.org/show_bug.cgi?id=1363508#c5
If Pointer Events is disabled but the browser sends Mouse Events in their place, then we could turn off the API and eliminate the fingerprinting properties of the API without significantly hurting browser functionality. Sure, fancy image editing apps that would rely on the nuances of a stylus movement wouldn't work, but if a user is trying to click on DOM element, that would still work. Am I thinking about it right?
In my case, I was expecting to be able to use
PointerEventas a kind of more generalMouseEvent; that is, I'm designing primarily for mouse use, but it would be nice if I can handle touch and stylus events in the same event handlers. I think this notion is congruent with:https://bugzilla.mozilla.org/show_bug.cgi?id=1363508#c6
The hope is that in the long run web pages move away from mouse and touch events and use just pointer events.
and:
https://w3c.github.io/pointerevents/#intro
To reduce the cost of coding to multiple input types and also to help with the above described ambiguity with Mouse Events, this specifications defines a more abstract form of input, called a pointer. A pointer can be any point of contact on the screen made by a mouse cursor, pen, touch (including multi-touch), or other pointing input device.
In short, I expected to receive mouse events in
pointerdown/pointerup/pointermoveevent handlers.-
I encountered a problem caused by the removal of pointer events
Well,
dom.w3c_pointer_events.enabledwas removed in FF87 .. whichmayposes some FPing issues .. meanwhile, test your heart out with mouse vs pointer vs touch - https://patrickhlauke.github.io/touch/
added Icebox label
removed Fingerprinting label
added Roadmap::Future + 1 deleted label
being tracked here: #28535
