Bug 517 - Command-scroll is too easy to activate by accident
Summary: Command-scroll is too easy to activate by accident
Status: RESOLVED FIXED
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Text Editor ()
Version: Trunk
Hardware: PC Mac OS
: Low normal
Target Milestone: ---
Assignee: Mike Krüger
URL:
Depends on:
Blocks:
 
Reported: 2011-08-29 09:05 UTC by Alan McGovern
Modified: 2012-05-23 08:51 UTC (History)
2 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED FIXED

Description Alan McGovern 2011-08-29 09:05:56 UTC
I constantly scroll while holding command and this ends up zooming my code. Can this be disabled?
Comment 1 Alan McGovern 2011-08-29 09:17:35 UTC
Just to add: This is an accident on my part when this happens. I've usually just hit command-x, command-c or command-v and start scrolling before I take my hands off the command button.
Comment 2 Mikayla Hutchinson [MSFT] 2011-08-29 10:47:14 UTC
I think we could fix this to make it harder to activate by accident.

Instead of inspecting the keyboard modifier keys in the mouse scroll event handler,  we could use a "scroll-modifier" flag managed by the text editor. The editor would set this flag when the command key was pressed (control on windows/linux), and clear it when the key way released or when *any* other key was pressed. That would prevent triggering it when the modifier had been used as part of keyboard shortcut.
Comment 3 Alan McGovern 2011-09-25 19:02:09 UTC
The sequence which I keep doing to activate this is when I'm hitting cmd-w to close open code files. I press and hold command, and then press and release 'w' to close a file. Sometimes I want to scroll the file and don't release 'cmd' in time and *boom*, I end up zooming.

Zooming is such an uncommon operation I don't think it should be so easy to activate accidentally.
Comment 4 Alan McGovern 2011-09-25 20:15:14 UTC
Or just scroll and press 'command' before the editor has finished scrolling. If you press command after you finish scrolling the mouse wheel but before the editor has finished scrolling, you start zooming.
Comment 5 Mike Krüger 2012-05-18 06:35:04 UTC
The real fix for this is not to scroll with with option+scroll (btw. why it is the option key atm - that  would fix the command problem too btw. ?)

On mac programs don't have this shortcut - instead there is a zoom event for zooming. But that's atm not supported on gtk.
I don't see a way to handle that on text editor level. If you hold the modifier the generated zoom events will have the key - even before a key event is generated.

@mhutch: can you take a look if we can get the zoom event on mac somehow. That's the cleanest way doing that - and we should support that, on mac this is the way to do zooming.
Comment 6 Mikayla Hutchinson [MSFT] 2012-05-18 13:15:05 UTC
Um, we can ask Lanedo to expose the zoom gesture event etc. on MacOS GTK+, but that's a separate enhancement IMO. Filed as bug 5176.

We'll still have the original problem on Windows, or on Macs when the user is using a normal mouse. That's why I suggested a mechanism to make it less likely to trigger accidentally - monitor the key events, and detect when the command/control key has been pressed and no other key has been pressed before it was released. Then the scroll event would only zoom if that flag is set.
Comment 7 Mike Krüger 2012-05-18 16:33:24 UTC
Windows has no smooth scroll events. The issue is that scroll events are on a timer on mac - that's not the case on windows.
Comment 8 Mikayla Hutchinson [MSFT] 2012-05-18 17:08:35 UTC
It has nothing to do with a timer - putting scroll events on a timer would actually make this less likely.

See comment 1. This has a very specific cause: user presses some command-x combination, then scrolls before releasing the command key.
Comment 9 Mike Krüger 2012-05-19 03:42:10 UTC
It has to do with a timer - the scroll events on windows occur on scroll where the mac scroll events occur when the scroll gesture is already done and the user presses command-combination AFTER the scrolling gesture.

That's different in windows where you've a mouse wheel and instant scrolling.
Comment 10 Mike Krüger 2012-05-21 07:09:33 UTC
btw. is there some application on windows where the control+zoom is different than ours ?
Comment 11 Mikayla Hutchinson [MSFT] 2012-05-21 13:53:24 UTC
I don't know any app on Windows that behaves differently, no.

And my point stands, this bug was reported about zooming immediate after the command, not making a command immediately after zooming. The second case has never been reported to be a problem in practice.
Comment 12 Mike Krüger 2012-05-21 14:07:16 UTC
The thing is that on windows you scroll -> immediate result.

On mac you scroll -> the editor scrolls 'smooth' (and generates scroll events on a timer) and while the smooth scroll occurs and you hold command -> zoom.

That's something that's not yet the case on windows. It would be good if the generated scroll events could be distinguished from the first or 'regular' scroll events.
Comment 13 Mikayla Hutchinson [MSFT] 2012-05-21 14:44:31 UTC
Oh, my bad, you meant the kinetic scrolling, not the smooth deltas.  That's easy to fix:

bool hasZoomModifier = (eventModifier & zoomModifier) != 0;
if (hasZoomModifier &&  (eventTime - lastScrollTime) < 1000) {
    hasZoomModifier = false;
} 

if (hasZoomModifier) {
    Zoom ();
} else {
    Scroll ();
    lastScrollTime = eventTime;
}
Comment 14 Mike Krüger 2012-05-23 08:51:52 UTC
Until we've the zoom event that'll work / fixed.