New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 47 users
Status: Fixed
Owner:
Closed: Mar 2014
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows
Pri: 2
Type: Bug


Sign in to add a comment
Zoom event (Ctrl+MouseWheel) not "cancelable" by javascript
Reported by joel.sch...@dental-wings.com, Jan 23 2012 Back to list
Chrome Version       : 16.0.912.75 (Official Build 116452) m
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Other browsers tested:
     Safari 5: ?
  Firefox 4.x: OK
     IE 7/8/9: OK

What steps will reproduce the problem?
1. Scroll the mouse wheel while pressing Control on a div that has prevented the event to complete (event.stopPropagation() and event.preventDefault() )

What is the expected result?
Nothing should happen.

What happens instead?
The page is zoomed.

Please provide any additional information below.
The problem has occurred for me while developing with GWT. I signalled this bug to the GWT team but it seems it is a browser problem : http://code.google.com/p/google-web-toolkit/issues/detail?id=7125
The minimal code to validate this issue can also be found here : http://stackoverflow.com/questions/8885299/how-to-catch-zoom-event-with-gwt-and-chrome
 
Is this issue missing something to be confirmed ?
Or is this only a matter of (low) priority ?
Project Member Comment 2 by bugdroid1@chromium.org, Mar 10 2013
Labels: -Area-Undefined
Comment 3 by Deleted ...@, Apr 9 2013
It's terrible!
Why have they not want to fixed this issue since Jan 23, 2012??????
Comment 4 by a...@lagoa.com, Jul 17 2013
Check out this small demonstration: http://jsfiddle.net/KyLN5/

In Windows 8:
Google Chrome version 28.0.1500.72 m induces a zoom change on control+mousewheel over the div.
Firefox 22 correctly blocks the zoom.

In Mac OS X 10.7.5:
Google Chrome version 28.0.1500.71 induces no zoom change on control+mousewheel anywhere.
Firefox 22 correctly blocks the zoom event over the div, and still allows zooming when not over the div.

In Ubuntu:
Chrome results are same as Windows, but at version 28.0.1500.71.
Firefox 20 works correctly.
Cc: rponnada@chromium.org
Labels: OS-Linux M-30 Cr-Blink-JavaScript
Status: Untriaged
Able to repro this issue on windows7 & Linux with build: 28.0.1500.72. Issues is not happening in MAC

This is non-regression issue, behavior is exists from M26.

Comment 6 by kareng@google.com, Aug 19 2013
Labels: -M-30 MovedFrom-30 M-31
Moving all non essential bugs to the next Milestone.
Project Member Comment 7 by bugdroid1@chromium.org, Sep 27 2013
Labels: -M-31 MovedFrom-31
This issue has already been moved once and is lower than Priority 1,therefore removing mstone.
OK, seems it won't be addressed until a while...
This is critical bug for our app. IE10 and FF work perfectly and allow us to override Ctrl+Wheel behaviour. Chrome is the only browser that does not work correctly.
Comment 10 by roc...@gmail.com, Oct 18 2013
Agreed.  Sadly we need to work around this with a shift+mousewheel in chrome.
Comment 11 by zupf...@gmail.com, Nov 10 2013
Important use case: Implementing Ctrl+mousewheel zooming to the point under the mouse pointer in a web app while leaving all UI elements alone, analogously to many desktop applications like Adobe Reader.
Cc: glen@chromium.org dmazz...@chromium.org jliebrand@chromium.org
Owner: raymes@chromium.org
Status: Assigned
Taking this because I'd like to hopefully see a resolution in the context of the PDF viewer extension I'm working on. This would also be really nice to have for the QuickOffice viewer.

Glen, Dominic, are there any UX/accessibility related issues here? We allow people to override other browser shortcuts including ctrl++, ctrl+-, is there a particular reason we don't allow it for zooming with the mouse? Other browser vendors seem to allow this as well.

Cc: pkasting@chromium.org
If you CCed me for a random opinion on comment 12, my answer would be that it seems fine to allow overriding these to me.
Comment 15 by robwu...@gmail.com, Feb 18 2014
Attached file: A HTML file to guide how to manually test whether https://codereview.chromium.org/165143003/ fixes the bug without introducing any regressions.
manual-tests.html
1.8 KB View Download
Project Member Comment 16 by bugdroid1@chromium.org, Feb 18 2014
The following revision refers to this bug:
    http://src.chromium.org/viewvc/blink?view=rev&rev=167355

------------------------------------------------------------------------
r167355 | rob@robwu.nl | 2014-02-18T19:05:51.010299Z

Changed paths:
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/page/EventHandler.cpp?r1=167355&r2=167354&pathrev=167355

Do not handle mouse wheel events when Ctrl is pressed

This commit does not change existing behavior.

Previously, the renderer would not see Ctrl+scrollwheel at all, because
these were intercepted early and not passed to the renderer.
However, this has changed in https://codereview.chromium.org/165143003/,
to allow web pages to catch and handle the event.

To allow the browser to handle Ctrl+scrollwheel (zooming),
handleWheelEvent now ignores the event when Ctrl is pressed.

Contributed by Rob Wu <rob@robwu.nl>

BUG= 111059 

Review URL: https://codereview.chromium.org/168493002
------------------------------------------------------------------------
I didn't realize this was going on here!  This is a sub-piece of a larger work item I'm doing in  issue 289887 .  See, for example, this chromium-dev thread: https://groups.google.com/a/chromium.org/forum/#!searchin/chromium-dev/mousewheel$20byers/chromium-dev/L_kaBhYFi5U/RIMFBx12dJoJ.  Sorry I didn't spot the overlap sooner!

In particular, I believe the below changes (including the one in c#16) mean this bug is now fixed.  Let me know if you're happy with the current behavior now.

------------------------------------------------------------------------
r253923 | rbyers@chromium.org | 2014-02-27T21:05:41.644709Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/shell/renderer/test_runner/EventSender.cpp?r1=253923&r2=253922&pathrev=253923

EventSender: Allow modifiers to be set for wheel events

BUG= 289887 

Review URL: https://codereview.chromium.org/183473002
------------------------------------------------------------------------

------------------------------------------------------------------------
r168088 | rbyers@chromium.org | 2014-02-28T08:12:56.591200Z

Changed paths:
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/events/wheelevent-ctrl.html?r1=168088&r2=168087&pathrev=168088
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/page/EventHandler.cpp?r1=168088&r2=168087&pathrev=168088
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/events/wheelevent-ctrl-expected.txt?r1=168088&r2=168087&pathrev=168088

Disable scrolling on mousewheel events with ctrl modifier set

Chromium currently swallows all mousewheel events with the ctrl modifier set (for zooming) instead of sending them to the renderer.  I plan to change this to align with Firefox and IE - send the event first, and if it goes unhandled then invoke browser zoom.  See  http://crbug.com/289887  and the linked chromium-dev thread for discussion.

In order to do that I need to ensure ctrl+wheel events don't trigger scrolling by default.  EventHandler::handleWheelEvent already has an early-out for the ctrl modifier case, but it's not enough since the default wheel handler has already been run.  This changes adds an identical early-out to EventHandler::defaultWheelEventHandler.

Test depends on EventSender change here: http://crrev.com/253923

BUG= 289887 

Review URL: https://codereview.chromium.org/183403002
------------------------------------------------------------------------

------------------------------------------------------------------------
r254559 | rbyers@chromium.org | 2014-03-03T21:04:13.093893Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/renderer_host/render_widget_host_impl.cc?r1=254559&r2=254558&pathrev=254559
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/web_contents/web_contents_impl_unittest.cc?r1=254559&r2=254558&pathrev=254559
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/web_contents/web_contents_impl.cc?r1=254559&r2=254558&pathrev=254559
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/web_contents/web_contents_impl.h?r1=254559&r2=254558&pathrev=254559
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/renderer_host/render_widget_host_delegate.cc?r1=254559&r2=254558&pathrev=254559
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/renderer_host/render_widget_host_delegate.h?r1=254559&r2=254558&pathrev=254559
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/renderer/input/input_handler_proxy_unittest.cc?r1=254559&r2=254558&pathrev=254559
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/renderer/input/input_handler_proxy.cc?r1=254559&r2=254558&pathrev=254559
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/renderer_host/render_widget_host_unittest.cc?r1=254559&r2=254558&pathrev=254559

Give blink a chance to consume ctrl+wheel events before zooming

Today chromium consumes all mouse wheel events when the control key is pressed for the purposes of browser zoom (except on MacOS).  With this change we give the web page a chance to get and consume the wheel event first, in case it wants to override the behavior.  This makes Chrome consistent with IE and Firefox on Windows.  See  http://crbug.com/289887  and the linked chromium-dev thread for discussion.

Apparently there were no tests at all for this functionality.  I've added new unit tests at RenderWidgetHost and WebContents layers.

Depends on blink change http://src.chromium.org/viewvc/blink?view=rev&rev=168088

BUG= 289887 

Review URL: https://codereview.chromium.org/177213016
------------------------------------------------------------------------
Blocking: chromium:289887
Cc: raymes@chromium.org
Labels: M-35
Owner: rbyers@chromium.org
Status: Fixed
Looks like my CL includes all aspects of the in-progress CL https://codereview.chromium.org/165143003/ (with a few differences in implementation that I don't think matter, plus some automated tests).  So I think this is essentially equivalent.

Funny that this has been a longstanding issue and we both basically decided to put similar CLs up to try to fix it about the exact same time :-) 
Blocking: chromium:323164
Blocking: chromium:352474
Project Member Comment 23 by bugdroid1@chromium.org, Mar 28 2014
The following revision refers to this bug:
  http://src.chromium.org/viewvc/blink?view=rev&rev=170238

------------------------------------------------------------------
r170238 | rbyers@chromium.org | 2014-03-28T01:22:23.564497Z

Changed paths:
   M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/events/wheelevent-ctrl.html?r1=170238&r2=170237&pathrev=170238
   M http://src.chromium.org/viewvc/blink/trunk/Source/platform/scroll/ScrollableArea.cpp?r1=170238&r2=170237&pathrev=170238
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/page/EventHandler.cpp?r1=170238&r2=170237&pathrev=170238
   M http://src.chromium.org/viewvc/blink/trunk/LayoutTests/fast/events/wheelevent-ctrl-expected.txt?r1=170238&r2=170237&pathrev=170238

Prevent ctrl+wheel from scrolling in more places

Chromium now sends ctrl+wheel events to webkit first before using them for zooming. Rather than prevent scrolling for these events in EventHandler::handleWheel, push that check a couple levels deeper into ScrollableArea::handleWheelEvent.  In addition to EventHandler, this code is also called by WebPluginScrollbarImpl and so will fix some additional cases.

This is mostly already tested by the fast/event/wheelevent-ctrl.html test I added in http://crrev.com/183403002.  I've extended that test to cover document and div scrolling cases and ensured it fails reliably if either the ScrollableArea or EventHandler::defaultWheelEventHandler check is removed. 

BUG= 352474 ,  111059 

Review URL: https://codereview.chromium.org/212913002
-----------------------------------------------------------------
Blocking: chromium:397027
Sign in to add a comment