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

Unexpected Mouse-Wheel scroll behavior #5550

Open
zlavergne opened this issue Dec 4, 2018 · 13 comments
Open

Unexpected Mouse-Wheel scroll behavior #5550

zlavergne opened this issue Dec 4, 2018 · 13 comments
Labels
compatibility An issue with hardware or software support help wanted For intermediate contributors, requires investigation or knowledge of iD code

Comments

@zlavergne
Copy link

System

Running Chrome 70.0 & Safari 12.0.1 on Mojave 10.14

Actual Behavior

When using the mouse-wheel scroll, the map pans rather than zoom. Zooming is activated when holding ctrl or alt/option then scrolling with the wheel.
The behavior on the trackpad works how I believe it's supposed to work (2 finger vertical movement will pan).

Expected Behavior

When using a mouse, scrolling the wheel should zoom the map rather than pan.

@bhousel bhousel added usability An issue with ease-of-use or design help wanted For intermediate contributors, requires investigation or knowledge of iD code labels Dec 11, 2018
@bhousel
Copy link
Member

bhousel commented Dec 11, 2018

I think #5505 might make it more possible to fix this

@zlavergne
Copy link
Author

I started trying out PointerEvents but I still haven't been able to find a way to differentiate between mouse-wheel and touchpad scrolls. Both the trackpad and the mouse register as a mouse device to a PointerEvents (Chrome & Firefox). It looks like it's dependent on the browser whether or not we can make the distinction.

@bhousel
Copy link
Member

bhousel commented Dec 12, 2018

I started trying out PointerEvents but I still haven't been able to find a way to differentiate between mouse-wheel and touchpad scrolls. Both the trackpad and the mouse register as a mouse device to a PointerEvents (Chrome & Firefox). It looks like it's dependent on the browser whether or not we can make the distinction.

Can you count the number of touches? e.g. on pointerdown increment a counter, pointerup decrement it... then in the zoomPan handler (which is responding to wheel events), if pointerCount < 1 make sure it zooms instead of pans.

@sookoll
Copy link

sookoll commented Jan 26, 2019

Why it changed at first place? Two fingers on trackpad for scroll is common behaviour. You can pan with click and drag on trackpad. Current solution is so inconvenient, that I have give up multiple times editing. I also have magic mouse and there is no way to zoom without keyboard. It is stupid change and there should be at least settings to turn it off to normal behaviour.

@bhousel
Copy link
Member

bhousel commented Jan 26, 2019

@sookoll Sorry to hear you are having issues with this also. The "Expected Behavior" in the issue is how it works for myself and most users that use iD. It's really pretty wonderful to have iD work just like Maps.app on a Mac. As a bonus, it's also impossible to accidentally drag nodes when you 2-finger pan the map.

I do want to improve the experience for users with a Magic Mouse, and would welcome any input that you can provide into how it dispatches scroll or wheel events in your preferred browser.

If you're willing to dig into the code, here is the relevant section of the event handler where we process the wheel events: https://github.com/openstreetmap/iD/blob/master/modules/renderer/map.js#L401

@jfirebaugh
Copy link
Member

I also find the change from two-finger trackpad zoom to two-finger trackpad pan quite jarring. It's contrary to how the vast majority of maps on the web work, including the main map on osm.org. Why force newcomers to learn two different interaction models on the same site?

@jfirebaugh
Copy link
Member

Plus I've hit #5552 about a half-dozen times in 10 minutes of editing.

@quincylvania quincylvania added compatibility An issue with hardware or software support and removed usability An issue with ease-of-use or design labels Sep 14, 2020
@1ec5
Copy link
Collaborator

1ec5 commented Aug 21, 2021

Personally, I appreciate the swipe-to-zoom feature from 45a3e58 for the following reasons:

  • Swipe-to-zoom is consistent with native Mac applications, everything from Maps.app to Preview.app to Sketch.app. After all, iD is a drawing application.
  • It’s more convenient to pan without dragging, reducing the likelihood of messing up the map by inadvertently dragging nodes.
  • When mapping, panning is so much more common than zooming that swipe-to-zoom reduces strain for folks with RSI (ow!), especially when using Apple trackpads that don’t have physical buttons.

That said, I completely understand that this feature can be jarring to anyone who spends more time in a Web browser than a desktop graphics editor.

In principle, swipe-to-zoom should not prevent the user from zooming using a Magic Mouse. In native macOS applications, double-clicking should zoom in, while double-tapping should zoom out (as long as the “Smart zoom” preference is enabled in the Mouse panel of System Preferences). But I’m not sure if the native events are exposed straightforwardly as DOM events. (If you use a conventional mouse with a scroll wheel, iD also lets you zoom by holding down the Control or Option key while swiping up and down: #5508.)

there should be at least settings to turn it off to normal behaviour.

iD now sports a Preferences pane, so I suppose it would be possible to give users a choice of scrolling behaviors. When I ported the Mapbox Maps SDK to macOS, I gave it the same swipe-to-zoom behavior that native applications should have, but people familiar with other platforms kept asking, so I added a preference and avoided unnecessary consternation: mapbox/mapbox-gl-native#4685.

@LaoshuBaby
Copy link

LaoshuBaby commented Aug 9, 2022

[This is just a bug report.] I've using iD and Firefox since I create my OSM account and everything work well, today my iD suddenly occur this issue.

I tested on Firefox 103.0.1, Chrome 103.0.5060.134, Edge 104.0.1293.47

And only Firefox occur this issue. (I try to open a privacy window in firefox, and this don't happen)

Touchpad works well, but mouse-wheel zoom in/out let map pan vertical.


I also found a OSM Forum thread that meet with same question like me: https://forum.openstreetmap.org/viewtopic.php?id=72396 (I also try a lot of shortcut to test whether it's my wrong touch, XD)

@1ec5
Copy link
Collaborator

1ec5 commented Aug 9, 2022

Touchpad works well, but mouse-wheel zoom in/out let map pan vertical.

What kind of mouse do you have? When I use a mouse with a physical mouse wheel in Firefox 103.0.2 on macOS, it zooms in and out. Meanwhile, swiping the touchpad still zooms in and out, incorrectly in my opinion: #8649.

@LaoshuBaby
Copy link

Here are some information for debug:

  • I‘m using a simple, cheap and conventional USB HID mouse, left, right, and a wheel, no other button. No special driver software such as "Logitech" installed, also not a Apple Magic Mouse.
  • Double left click still can zoom in
  • Change between display 1 and 2 don't have effort.
  • Press - and + still can zoom in, and click [-] or [+] button on the right control bar still valid.
  • Ctrl+F5 force reload js file, clean cache of osm.org, reopen this tab, restart Firefox, those common debug method don't have effort. I even reboot my laptop.
  • F12 console haven't seen some extra warning/error.
  • System is Windows 11 Professional Insider Preview Build 25151.rs_prerelease.220625-1835, but I don't think this matter because everything normal utill yesterday.

And I Also record some video in 7 situation, most of my try don't occur this issue.

① RapiD works correctly
iD-1.mp4
② iD on OSM Website failed
iD-2.mp4
③ Even another iD on OpenGeofiction can‘t zoom
iD-3.mp4
④ Privacy Window work well
iD-4.mp4
⑤ Chrome work well(Also Edge but I haven’t record)
iD-5.mp4
⑥ With `Ctrl` key pressed
iD-6.mp4
⑦ Touchpad operation
iD-7.mp4

@1ec5
Copy link
Collaborator

1ec5 commented Aug 9, 2022

Thanks for the detailed screen recordings. Since you began experiencing this issue only recently, there’s probably something else going on that’s independent of the original bug report (but still closely related). Note that the code for handling scroll wheel events varies by browser and in Firefox currently differs between macOS and other platforms because of the workaround for making scroll wheels zoom (at the expense of touchpads).

@LaoshuBaby
Copy link

Aha! I may found what happen!

I just want to undo my last step and found Ctrl+Z can't use, when I want to manual click the undo button, the syntax confused me because I'm using Windows at all!

图片

Then I noticed why I'm seen as MacOS, I want to make some test on another project and set UA to Chrome on MacOS, and that setting haven't be refreshed:

图片

That's my fault, all of this inconvenience is made by myself. Sorry for bother everyone in this thread.

I disable it, then everything work correctly.


BTW, I still want to say I can use my Ctrl key in many other website, such as Github, Twitter, Weibo. And they act correctly to my swipe and scroll. So I haven't found my UA wrong.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compatibility An issue with hardware or software support help wanted For intermediate contributors, requires investigation or knowledge of iD code
Projects
None yet
Development

No branches or pull requests

7 participants