Two-finger swipe on trackpad zooms map instead of panning

[1ec5]

Starting in v2.20.1, swiping with two fingers on a multitouch trackpad zooms the map in and out instead of panning in every direction. Reproduces in Firefox 91.0 on macOS. Does not reproduce in Safari 13.1.

/ref #8595

[1ec5]

Oh, I just noticed that this functionality was intentionally removed from Firefox for macOS in favor of letting scroll wheel mice zoom in and out: #8595 (comment) webcompat/web-bugs#73148. For what it’s worth, I never had a problem using both two-finger pan and scroll-wheel zoom in in iD v2.19 on my MacBook Pro in Firefox 91 or earlier. (I even briefly used Firefox 56 without any problems.) However, my mouse has a low-precision scroll wheel, not like an Apple mouse.

[1ec5]

(I goofed up, saved too soon, and ended up having to rewrite this comment and split out much of it as #5550 (comment). Sorry for jumping the gun with something that came off as accusatory.)

#8595 seems to have conflated two different issues:

• Two-finger swiping on a trackpad scrolls the page in Safari on iPadOS, causing the page to bounce, previously fixed in Disable elastic page scrolling on Safari and mobile Safari #7576.
• Spinning a scroll wheel pans the map vertically in Firefox on macOS, also reported in Unexpected Mouse-Wheel scroll behavior #5550 openstreetmap.org - Mouse wheel does not zoom into the page webcompat/web-bugs#73148.

Only the latter relates to the the swipe-to-pan feature added in 45a3e58. 2270b5d closed the issue by disabling swipe-to-pan only in Firefox.

I haven’t completely dug into the discussion at webcompat/web-bugs#73148, but there’s some disagreement as to whether it also reproduces in Chrome and Safari, so I wonder if other variables are at play. Completely disabling the feature seems like an overcorrection, while disabling it only in Firefox seems like an undercorrection, so hopefully we can find a more targeted fix.

I tested iD before and after this change on macOS 10.13 using the following input devices:

• Logitech M-BJ87B, a two-button mouse with a conventional, imprecise scroll wheel
• Magic Mouse, a multitouch mouse with no physical buttons and no scroll wheel
• The multitouch trackpad on a late 2013 MacBook Pro with no physical buttons and no scroll wheel

I have dom.event.wheel-deltaMode-lines.disabled set to true (the default) in Firefox 91.

Application		Two-button mouse	Multitouch mouse	Multitouch trackpad
		Scroll wheel	One-finger swipe	Two-finger swipe
iD v2.20.0	Firefox 56	Zoom	Pan	Pan
	Firefox 91	Pan ⚠️	Pan	Pan
	Safari	Zoom	Pan	Pan
iD v2.20.1	Firefox 56	Zoom	Zoom ⚠️	Zoom ⚠️
	Firefox 91	Zoom	Zoom ⚠️	Zoom ⚠️
	Safari	Zoom	Pan	Pan
Maps.app		Zoom	Pan	Pan
Preview.app		Zoom	Pan	Pan
Inkscape		Pan	Pan	Pan

Ironically, if you use Firefox and a multitouch input device, you now have two ways to zoom without clicking (three with a trackpad) but no way to pan without clicking.

[1ec5]

This issue is important to me because the current behavior potentially puts some Firefox users at risk of injury. Panning is a much more common operation than zooming when mapping. My primary input device is a trackpad, though I do have a mouse that’s also affected by this issue. I experience carpal tunnel syndrome but have to click and drag constantly in order to map. For the past year, my workaround has been to spoof my user agent as Safari, but this should not be a requirement for users less familiar with Web development.

So far, in Firefox 101 on macOS, I haven’t found any distinction in the DOM between wheel events generated by a scroll wheel versus a swipe on a multitouch mouse or trackpad. Assuming there is no difference, can we consider a “Scrolling pans the map” checkbox in the Preferences pane, as a workaround?

[1ec5]

I found a way to distinguish a multitouch mouse or trackpad (which should pan the map) from a scroll wheel mouse (which should zoom the map).

By default, when a traditional scroll wheel mouse is connected, macOS adds a traditional scrollbar to any element that overflows with a scrollbar. Otherwise, macOS uses an overlay scrollbar, which doesn’t affect the size of anything contained inside the element. As a workaround for the issue above, we could add an invisible <div> to the document that scrolls:

height: 100px;
overflow: scroll;
position: absolute;
top: -200px;
visibility: hidden;
width: 100px;

then check the width of the <div>’s scroll box:

let hasOverlayScrollbar = hiddenScrollingElement.scrollWidth == 100;

If the scroll box’s width matches the element’s declared width, then overlay scrollbars are enabled. Otherwise, if the width is less, then traditional scrollbars are enabled. Overlay scrollbars are enabled when either a multitouch input device is connected or the “Show scroll bars” option in General Settings is set to “Always”:

I think it’s safe to assume that most users have this preference set to “Automatically based on mouse or trackpad”. It isn’t difficult to set it to “Always” or use the trackpad while a mouse is connected. But these edge cases are so obscure that I think we can afford to regress them.

[1ec5]

RapiD has more or less addressed this issue by adding a user preference for the mouse wheel interaction mode: facebook/Rapid#680 (comment). If RapiD incorrectly detects a trackpad where it should detect a mouse wheel, the preference allows the user to override this default, avoiding injury from having to click and drag too often.