Open Bug 1849690 Opened 1 year ago Updated 11 months ago

css touch-action doesn't affect laptop touchpads

Categories

(Core :: Panning and Zooming, enhancement, P3)

Firefox 115
enhancement

Tracking

()

UNCONFIRMED

People

(Reporter: nashjames.dev, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/115.0

Steps to reproduce:

  1. Added the touch-action: none; property to a website to prevent gesture zooming
  2. Test on iPhone Safari - works!
  3. Test on MacBook Firefox - doesn't work :(
  4. Test on Windows Firefox - doesn't work :(

Actual results:

No effect. Zoom option still available

Expected results:

Gesture zooming should be prevented on the website.

My work involves creating something adjacent to Google Maps and this causes massive issues with users unexpectedly zooming the browser, rather than the map when hovering over map pins.

This issue also exists with Chromium browsers, however I wasn't sure where the responsibility is. Please advise if this is something you can fix or if I need to report the issue with OS manufacturers or with web standards.

Thanks!

The Bugbug bot thinks this bug should belong to the 'Core::Layout' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Layout
Product: Firefox → Core

Firefox probably ignores CSS touch-action on platforms without touch events. Switch components to APZ so that Botond or Hiro can confirm my theory.

Component: Layout → Panning and Zooming
Flags: needinfo?(hikezoe.birchill)
Flags: needinfo?(botond)

Coincidentally Botond and I discussed about whether touch-action should affect on gestures on touchpad or not. See bug 1848062 comment 4 and bug 1848062 comment 5. Our current conclusion is to keep our current behavior match others (since none of browsers does respect touch-action on touchpads).

That being said, I don't object your opinion at all. I'd rather be supportive. I think the best course you can take is to open a new spec issue on here. Thanks!

Severity: -- → S3
Type: defect → enhancement
Flags: needinfo?(hikezoe.birchill)
Flags: needinfo?(botond)
Priority: -- → P3
See Also: → 1848062

(In reply to Ting-Yu Lin [:TYLin] (UTC-8) from comment #2)

Firefox probably ignores CSS touch-action on platforms without touch events

To be more precise, we currently respect touch-action only for input methods which produce touch events.

So, if you have a Windows laptop with a touchscreen and a touchpad, then double-tap zoom on the touchscreen is currently prevented by touch-action, but double-tap-zoom on the touchpad is not.

Brilliant. Thank you all!

Especially for the added direction on where to raise this discussion further!

I will create an issue with web standards and see where that goes.

we currently respect touch-action only for input methods which produce touch events

per the spec, touch-action would apply to any "direct manipulation" input methods. In this case, however, my question would be: is the gesture performed on the trackpad analysed/processed by the browser itself, or is it lower down (e.g. some driver/utility at OS level) and what is actually being sent to the browser are effectively scrollwheel / CTRL+scrollwheel events? if the latter, it would probably not make sense/should not be directly possible to prevent the behaviour using touch-action, and the OP should instead listen for, and preventDefault(), scrollwheel events?

(In reply to Patrick H. Lauke from comment #6)

is the gesture performed on the trackpad analysed/processed by the browser itself, or is it lower down (e.g. some driver/utility at OS level) and what is actually being sent to the browser are effectively scrollwheel / CTRL+scrollwheel events?

Generally speaking it's the latter; the browser does not have access to information about individual touch points on the touchpad.

(In reply to Botond Ballo [:botond] from comment #7)

(In reply to Patrick H. Lauke from comment #6)

is the gesture performed on the trackpad analysed/processed by the browser itself, or is it lower down (e.g. some driver/utility at OS level) and what is actually being sent to the browser are effectively scrollwheel / CTRL+scrollwheel events?

Generally speaking it's the latter; the browser does not have access to information about individual touch points on the touchpad.

Ah, I suspected as much. In which case I would indeed suggest that touch-action would be inappropriate in this case, and that the more appropriate approach for the OP is to explore preventing scrollwheel events (otherwise, you would end up in a similarly strange situation where touch-action would otherwise prevent actual CTRL+scrollwheel actions done with a mouse rather than a trackpad/touchpad).

I am a bit confused. I suppose Ctrl+scrollwheel isn't gestures we will care. Pinch-in/out gestures on touchpad will be cared I suppose. In pinch-in/out cases there's no corresponding input events so preventDefault() will not be an option. Even if a new standard input event were defined, I'd prefer a declarative way to prevent pinch-in/out gestures. Though it may not be a part of touch-action, it's worth discussing in the standard group I suppose.

In pinch-in/out cases there's no corresponding input events

but that's my point: is the pinch gesture done on the touchpad actually translated (by the OS) to a CTRL+scrollwheel event that is then sent to the browser, and indistinguishable to the browser from an actual CTRL+scrollwheel? or can the browser detect that it's indeed a pinch on a touchpad. from my experience (and from what :botond is saying above), it's the former - and in that case, it's outside of the purview of, say, the Pointer Events specification for instance.

In some old type of touchpad cases, the OS sends wheel events (with Ctrl key modifier?) IIRC, but in these days (I suppose since around 2019?) the OS sends a dedicated message (via the DirectManipulation interface in the case of Windows), we use (translate) the message for pinch in/out.

via the DirectManipulation interface in the case of Windows

Ah, in which case, touch-action should be applicable then https://w3c.github.io/pointerevents/#declaring-direct-manipulation-behavior and indeed Firefox should honour it

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

In pinch-in/out cases there's no corresponding input events so preventDefault() will not be an option.

We do send the webpage a wheel event with the "Control" modifier set in response to touchpad pinch gestures (that happens e.g. here), and the webpage can preventDefault() that event to prevent the browser from performing its default zoom in response to the touchpad pinch.

This is how e.g. Google Maps hooks touchpad pinches to do custom zooming (re-render the map with higher or lower resolution tiles).

I'd prefer a declarative way to prevent pinch-in/out gestures

I agree that a declarative way to prevent touchpad pinch gestures would be valuable; this could be an argument for having touch-action apply to it.

(In reply to Patrick H. Lauke from comment #12)

via the DirectManipulation interface in the case of Windows

Ah, in which case, touch-action should be applicable then https://w3c.github.io/pointerevents/#declaring-direct-manipulation-behavior and indeed Firefox should honour it

DirectManipulation is the name of an api, Whether or not it counts as direct manipulation in that spec is another question.

(In reply to Botond Ballo [:botond] from comment #13)

We do send the webpage a wheel event with the "Control" modifier set in response to touchpad pinch gestures (that happens e.g. here), and the webpage can preventDefault() that event to prevent the browser from performing its default zoom in response to the touchpad pinch.

Yes. This is the general way that this problem is solved on the web at this time.

(In reply to Patrick H. Lauke from comment #10)

but that's my point: is the pinch gesture done on the touchpad actually translated (by the OS) to a CTRL+scrollwheel event that is then sent to the browser, and indistinguishable to the browser from an actual CTRL+scrollwheel? or can the browser detect that it's indeed a pinch on a touchpad. from my experience (and from what :botond is saying above), it's the former

To clarify:

  • While (1) touchpad pinch, (2) touchpad scroll with Ctrl held down, and (3) regular mouse-wheel scroll with Ctrl held down look the same to web content, in the browser we can distinguish between them (at least for newer / "precision" touchpads).
  • However, we don't have information about the individual touches (positions of individual fingers on the touchpad) that would allow us to generate touch events.

(In reply to Timothy Nikkel (:tnikkel) from comment #14)

DirectManipulation is the name of an api, Whether or not it counts as direct manipulation in that spec is another question.

Right, I think the question of whether touch-action should apply to touchpad gestures should be discussed in a spec issue and analyzed from first principles, such as:

  • Are there use cases where websites might want touchpad input and touchscreen input handled differently?
  • Are the requirements imposed on touchpad input implementable on all platforms with touchpads? Not every platform exposes touchpad input the same way as Windows.

Thanks everyone for the discussion on this.

There seems to be support for this from everyone, so I think there's potentially two options to get this resolved:

  1. It gets re-opened as a spec issue and the edge cases discussed through a slightly more official route
  2. I can open similar tickets with Chromium and Safari, and Firefox can use this ticket to track their own implementation

I'm happy with either but is there any particular preference before I go ahead?

As mentioned in comment 16, this should be discussed in a spec issue -- please go ahead and open one.

It's not clear to me yet what the resolution should be (for example, whether it's touch-action that should apply to touchpads or something new like touchpad-action) so we're not ready yet to track the implementation of anything.

I will add here that for the Pointer Events spec, we've tried to quite explicitly keep touch-action to be interpreted as a more general "direct manipulation" hint for UAs (so not purely touch - but we kept the name for compatibility reasons). with my chair hat off, I would not necessarily want to see further fragmentation/addition of more device/input specific CSS properties.

I noticed that a spec issue has been filed at https://github.com/w3c/pointerevents/issues/478, linking to it for reference.

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