Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mouse wheel scroll pans map #680

Closed
cbeddow opened this issue Dec 1, 2022 · 12 comments
Closed

Mouse wheel scroll pans map #680

cbeddow opened this issue Dec 1, 2022 · 12 comments
Labels
bug Something isn't working

Comments

@cbeddow
Copy link
Contributor

cbeddow commented Dec 1, 2022

Chrome browser, on Windows, with wireless mouse with hardware scroll wheel

I intend to zoom in and out on the map when I use the scroll wheel, but it seems to pan the map when zoomed in. Zoomed out completely, it seems to be vertical scrolling the map container and makes a red bar appear at bottom 5% or less of the map container.

@cbeddow cbeddow added bug Something isn't working alpha labels Dec 1, 2022
@Bonkles Bonkles moved this to Triage in Rapid v2 Beta Board Dec 1, 2022
@Bonkles Bonkles added this to the v2 General Beta (Extended) milestone Dec 1, 2022
@bhousel
Copy link
Contributor

bhousel commented Dec 1, 2022

Ah yeah this one might be tricky. I rewrote all the map interaction code a few months ago, but this is one of those areas where different browser/os/mouse combinations can do different things. Simplest fix might be to just add a toggle in the user preferences pane to let the user override what our wheel event handler does.

@boothym
Copy link

boothym commented Dec 8, 2022

Same here, though if you scroll the mouse wheel enough times it seems to pan the map up and then zoom in, and so on.

@bhousel bhousel added v2.beta and removed v2.alpha labels Feb 14, 2023
@nickrsan
Copy link

Also encountering this issue in the V2 Beta on Firefox 109.0.1 on Windows 10.

@1ec5
Copy link

1ec5 commented Feb 14, 2023

Simplest fix might be to just add a toggle in the user preferences pane to let the user override what our wheel event handler does.

This would also be a suitable workaround for openstreetmap/iD#8649 on Firefox on the Mac (which also affects RapiD).

@k-yle
Copy link
Contributor

k-yle commented Feb 15, 2023

Edge v110 on Windows 11:

  • swiping left/right with two fingers: ✓ works
  • swiping up/down with two fingers: ✗ zooms instead of panning
  • mouse scrollwheel: ✗ pans instead of zooming

@Bonkles
Copy link
Contributor

Bonkles commented Feb 17, 2023

Thanks so much for all the reports and corroborating information everybody! I'm taking a look at this today. Fortunately I can reproduce this on my home PC, unfortunately, it does NOT reproduce on my development machine, a macbook Pro (which is how this one slipped through the cracks).

Interestingly, this works on mac with both the built-in trackpad AND with a corsair wireless mouse with a scroll wheel. 🤷

@tyrasd
Copy link
Contributor

tyrasd commented Feb 17, 2023

I'm also experiencing the issue on Linux (Ubuntu) on both Firefox and Chrome/Chromium. FYI: I do have a mouse with a secondary "horizontal" mouse wheel (Logitech MX Master 3), and the secondary wheel pans the map horizontally while the main scroll wheel pans it vertically.

@1ec5
Copy link

1ec5 commented Feb 17, 2023

I think the original design was that an input device that’s capable of scrolling in two directions would get the panning behavior, while an input device that’s only capable of scrolling vertically would get the zooming behavior. But that’s difficult to map to the DOM events that come through, especially across browsers.

Regardless of the input device, some users also prefer one behavior over the other. For some users, panning any other way would induce RSI. Other users happen to specialize in a kind of mapping that requires more zooming than panning, such as reviewing buildings or participating in MapRoulette challenges built around point features. A preference would better accommodate these different use cases while offering an escape hatch when (Rap)iD doesn’t choose the most ergonomic default for the user’s environment.

@mxxcon
Copy link

mxxcon commented Feb 17, 2023

I think the original design was that an input device that’s capable of scrolling in two directions would get the panning behavior, while an input device that’s only capable of scrolling vertically would get the zooming behavior. But that’s difficult to map to the DOM events that come through, especially across browsers.

Regardless of the input device, some users also prefer one behavior over the other. For some users, panning any other way would induce RSI. Other users happen to specialize in a kind of mapping that requires more zooming than panning, such as reviewing buildings or participating in MapRoulette challenges built around point features. A preference would better accommodate these different use cases while offering an escape hatch when (Rap)iD doesn’t choose the most ergonomic default for the user’s environment.

I'd say majority of consumer users(ie coming from google maps) would expect wheel to zoom... It is also the default behavior on osm.org, iD and RapiD up to this point..

@1ec5
Copy link

1ec5 commented Feb 17, 2023

Yes, I’m generalizing a bit. If you have a conventional wheel, you expect zooming. After all, what’s the point of only being able to pan vertically? But if you have a multitouch-capable mouse or trackpad, it isn’t quite as clear-cut: it depends whether you associate (Rap)iD with a graphics editor or a browseable map, and also the factors I mentioned above. Whatever the default, this is just about the best case for a preference that has come up so far.

@thegrasshopper104
Copy link

Same with Linux and Firefox 110

bhousel added a commit that referenced this issue Feb 23, 2023
(re: #680)

This commit contains a bunch of cleanups in the event detection code
and related comments and documentation.
It probably doesn't fix the issue, but shouldn't make it worse either.

In summary:
The old v1 code default to "zoom", but would "pan" in some situations.
The buggy v2-beta code was default to "pan", but "zoom" in some situations.

The detection for whether to choose zoom or pan depended a lot on
whether the delta values where round number or fractional number.

On trackpads this works, however actual mousewheel zooms can have
round or fractional values - this can't be the deciding factor.

Going to test with Windows/Linux and other browsers some more to see
whether there is a more reliable method for detecting mouse 'wheel'
events (which should always "zoom" and never "pan")

Failing that, I'll just make it a configurable option.
@bhousel
Copy link
Contributor

bhousel commented Feb 24, 2023

I ended up making this behavior configurable on the preferences pane.
We might further tweak the "automatic" option to work better on non-Mac devices.

Screenshot 2023-02-24 at 3 17 34 PM

I added tooltips to explain what these options mean:

auto:
  title: Automatic
  tooltip: Best for trackpad users.  With 2 fingers, swipe gestures will pan the map, and pinch gestures will zoom and unzoom the map.  Holding down Shift will zoom and unzoom the map.
zoom:
  title: Zoom the Map
  tooltip: Scrolling with the wheel will always zoom and unzoom the map.
pan:
  title: Pan the Map
  tooltip: Scrolling with the wheel will pan the map.  Holding down Shift will zoom and unzoom the map.

@github-project-automation github-project-automation bot moved this from Triage to Pending Release in Rapid v2 Beta Board Feb 24, 2023
bhousel added a commit that referenced this issue Mar 2, 2023
(re: #680)

This commit contains a bunch of cleanups in the event detection code
and related comments and documentation.
It probably doesn't fix the issue, but shouldn't make it worse either.

In summary:
The old v1 code default to "zoom", but would "pan" in some situations.
The buggy v2-beta code was default to "pan", but "zoom" in some situations.

The detection for whether to choose zoom or pan depended a lot on
whether the delta values where round number or fractional number.

On trackpads this works, however actual mousewheel zooms can have
round or fractional values - this can't be the deciding factor.

Going to test with Windows/Linux and other browsers some more to see
whether there is a more reliable method for detecting mouse 'wheel'
events (which should always "zoom" and never "pan")

Failing that, I'll just make it a configurable option.
bhousel added a commit that referenced this issue Mar 2, 2023
bhousel added a commit that referenced this issue Mar 22, 2023
re: #856, #841, #680

It's mostly Windows where the autodection doesn't work as expected,
so default the mousewheel to zoom in that case, to avoid user frustration.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Status: Pending Release
Development

No branches or pull requests

10 participants