Project: chromium Issues People Development process History Sign in
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 20 users
Status: Verified
Owner:
Closed: May 2014
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug

Blocked on:
issue 111059
issue 352474



Sign in to add a comment
Make trackpad pinch gestures send (overridable) wheel events
Project Member Reported by rbyers@chromium.org, Sep 12 2013 Back to list
Chrome Version       : 31.0.1621.1

In  issue 227454  support was added for the DOM3 wheel event (http://www.w3.org/TR/DOM-Level-3-Events/#events-wheelevents).  One main way wheel event differs from our non-standard mousewheel event is that wheel event adds a 'deltaZ' property.  Currently we always return 0 for this (https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/dom/WheelEvent.cpp&sq=package:chromium&type=cs&rcl=1378422897&l=75).

The spec has an example that says:
"The user's environment might be configured to associate vertical scrolling with rotation along the y-axis, horizontal scrolling with rotation along the x-axis, and zooming with rotation along the z-axis."

From this perspective it seems reasonable to generate deltaZ wheel events for trackpad pinch gestures.  This would enable apps like google maps to respond nicely to pinch.

I brought this up on the intent-to-ship thread for wheel event and got no objections: https://groups.google.com/a/chromium.org/d/msg/blink-dev/1NjsGzOtA5M/EYOPqcb4w3gJ (although we should probably still check the behavior on other browsers and make sure we're consistent with the ones that implement deltaZ).

Anyone have any interest in picking this up?

We may want to file sub-bugs for the platform-specific pieces on Windows, MacOS and ChromeOS.
 
Comment 1 by rbyers@chromium.org, Sep 12 2013
Cc: davemoore@chromium.org
Note that on Mac (and maybe windows?) we trackpad pinch already has a default action in chrome - browser zoom.  That's fine - trackpad scrolling also has a default action (scroll) which can be overriding by web pages by calling preventDefault on the wheel event.  We just need to continue to follow that pattern - dispatch the wheel event first, and if JS doesn't call preventDefault on it, then do browser zoom.
Comment 2 by rbyers@chromium.org, Sep 12 2013
Cc: sadrul@chromium.org
Comment 3 by tha...@chromium.org, Sep 12 2013
Maps currently zooms on trackpad-scroll-up. If they hook up pinch, they probably want to do translation for trackpad scroll gestures (they currently can't since they can't distinguish these events from scroll wheel events). Is there a plan to make trackpad scroll gestures detectable by web apps too? Without that, this seems less useful.
Comment 4 by rbyers@chromium.org, Sep 12 2013
Cc: arv@chromium.org
Open questions:
- what scale/physics to use for the deltaZ "pixel" values?
- do we need a way to feature detect when Z is supported, or when a device capable of generating Z is attached?  Eg. Maps may want to use deltaY to zoom on a physical mouse, but deltaZ to zoom on a trackpad (and deltaX/deltaY to pan).  Perhaps its sufficient for the site to just look for the first non-zero deltaZ - it'll probably be hard to avoid in practice
- what do IE and FireFox do with deltaZ today?
- should we ever dispatch a wheel event with non-zero deltas AND deltaX/deltaY?  Doing so makes impossible for a page to prevent scrolling but not zooming or vice versa.

Comment 5 by rbyers@chromium.org, Sep 12 2013
Re #3 - right, I think that's the same as my 2nd point above. There are a few options.  High road is to get some addition to the spec.  I could ask on the W3C list.  

But low road, I suspect it'll be impossible to scroll without some small pinching, so non-zero deltaZ can be the signal that it's possible (we could even hack a tiny min value if necessary).
Comment 6 by rbyers@chromium.org, Sep 12 2013
By the way, see http://b.corp.google.com/issue?id=7742031 for some of the discussion with the maps team.
Comment 7 by tha...@chromium.org, Sep 12 2013
Re "impossible to scroll without some small pinching": While that's true at the trackpad driver level, at least OS X sends either a pinch or a scroll event as far as I know, so it's either-or for applications at least there. (Not that that's very relevant to the rest of the discussion :-) ).
Comment 8 by rbyers@chromium.org, Sep 12 2013
Summary: wire WheelEvent up to trackpad pinch gestures (was: wire WheelEvent.deltaZ up to trackpad pinch gestures)
Looks like both firefox and IE 10 on Win 8 don't use deltaZ for pinch.  Instead they use deltaY but with the 'ctrl' modifier set.  So trackpad pinch is identical to holding control and moving a normal mousewheel.  This solves my 4th point in c#4, but I think all the other open issues still stand.
Cc: meh@chromium.org
+meh to drive as part of his input project :)
Labels: -CR-UI-Input-Touch-Pad Cr-Internals-Input-Touch-Pad
Comment 11 by meh@chromium.org, Dec 2 2013
Rick, any update on this?  input-dev's priority is rightly latency reduction, but this is important e.g. for the zoomable maps use case.  If there's no update, let's prioritize in an early Q1 input bug triage.
Friendly Q1 ping :)
Labels: M-34
Owner: rbyers@chromium.org
Status: Assigned
I'm discussing with chrome UX folks whether we want to keep trackpad pinch-to-zoom behavior at all.  If we do then I think we should match firefox/IE behavior here: send ctrl mousewheel events, and if consumed suppress the zoom.  This will address maps P0 issue (accidental browser zoom) but won't directly enable trackpad pinch zoom (which will apparently require some new API).
Huh? If this doesn't allow pinch-zoom on maps to actually pinch-zoom on maps, doesn't it make much more sense to come up with an api that allows this? That would solve the accidental zoom issue _and_ implement a feature that lots of people want.

Synthesizing a weird event just so that web sites can cancel it without actually caring about the event sounds bad.
I agree a new API might be better, but realistically I don't think we could justify the effort for it (get other browser vendors on board - particularly difficult due to the IP issues around gestures, define a spec, etc.).  I'm happy if someone else wants to give that a shot (and I can provide my $.02), but it's not something my team can drive.

In contrast tweaking our implementation to match IE and firefox is pretty simple and probably not terribly controversial.  I'm happy to just implement that myself if it's what we want.
In general, that sounds reasonable. But it sounds like in this case the motivation is to implement this because the chromium and maps ui teams disagree about how a browser feature should work, and so we're providing a per-site hook to change this (via some elaborate event mechanism, because that's what other browsers have and which allows this through a side effect). This borders on madness, imho :-)
Comment 17 by mpd@google.com, Jan 8 2014
FWIW, it's not the maps UI team that's the problem, it's maps users who are trying to use a gesture that has been ingrained in them by the platform. 
Right, but they probably want the map to zoom, not do do nothing.
Comment 19 by mpd@google.com, Jan 8 2014
Agreed! Order of preference:

1) Map to zoom (achievable by firing scroll events with the ctrl key, a la IE and FF)
2) Do nothing
3) Browser zoom

If 1) isn't feasible or requires a big standards battle, we'd rather have 2) in the meantime!
That's what I thought, but then rbyers said in comment 16 "send ctrl mousewheel events…won't directly enable trackpad pinch zoom", which seems to contradict your "achievable by firing scroll events with the ctrl key".

Also, is ctrl-mousewheel universally accepted as zoom? on my mac, a real ctrl-mousewheel does screen magnification and never reaches apps, so that seems pretty hacky to me.

rbyers, haven't you shopped around some touch event spec for over a year now? What's wrong with a "onpinch" event? Is Mozilla opposed to that? Do Windows APIs not provide this kind of gesture?
Comment 21 by mpd@google.com, Jan 8 2014
I think issues like those in #20 are what drove rbyers to suggest that we don't do anything on pinch. ;) Seems easiest.

If ctrl-mousewheel isn't getting to the app (but isn't zooming the browser), that seems fine. Then on OSX we can be pretty sure that ctrl-mousewheel events are actually pinch to zoom.
I was imprecise in c#16 - sorry.  What I meant was "send ctrl mousewheel events ... wont directly enable the full trackpad pinch zoom / pan experience users expect".  Pinching will probably still zoom, but then users will probably try to pan with two-finger scrolling and get MORE zooming (since plain mousewheel still needs to zoom).  Maps might be able to use some heuristic to avoid this, but it would be hacky.

re #20 touch event spec: no, there's no real active spec that talks about pinch (because no-one wants to touch the IP implications).  The specs I've been working on are lower level (raw touch events, unified pointer events) and don't include this scenario.  The closest spec I'm aware of is Indie UI events: http://www.w3.org/TR/indie-ui-events/ - I tried to get them to spec the manipulation events to handle the maps scenarios.  It's been slow moving and last I looked around it's not yet clear if any browser is going to implement them, but I'm hopeful!
Comment 23 by mpd@google.com, Jan 9 2014
thakis@, I'm not clear on what you're advocating here. Status quo? This is a pain point for our users, so I'd like to come to some agreement about a way forward.
Labels: -Pri-2 -M-34 Pri-1 M-35
Agreement reached here: https://groups.google.com/a/chromium.org/forum/#!searchin/chromium-dev/mousewheel$20byers/chromium-dev/L_kaBhYFi5U/RIMFBx12dJoJ

It's probably too late for M34, but I'll make this a priority for M35.
Status: Started
I'm working on the first part (sending ctrl+wheel events to the renderer) here: https://codereview.chromium.org/177213016
Project Member Comment 27 by bugdroid1@chromium.org, Feb 27 2014
------------------------------------------------------------------------
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
------------------------------------------------------------------------
Project Member Comment 28 by bugdroid1@chromium.org, Feb 28 2014
The following revision refers to this bug:
    http://src.chromium.org/viewvc/blink?view=rev&rev=168088

------------------------------------------------------------------------
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
------------------------------------------------------------------------
Blockedon: -chromium:227454
Cc: rjkroege@chromium.org
The first step of making chrome and blink handle ctrl+wheel events properly is nearly done (last patch in the series is in review - https://codereview.chromium.org/177213016/).

Here's a brief summary of how I'm approaching implementing the trackpad support in case anyone has feedback:

Someday soon we probably want trackpad pinch gestures wired into our new pinch-zoom framework instead of browser zoom (at least on some platforms, if not all).  Also eventually we'd like to expose pinch events to the web.

So for now I'll have the platform-specific UI layers generate GesturePinch* events as we do for touchscreen, but flagged with source=trackpad (similar to what we do for trackpad GestureFling events today).  This code code should support all the future scenarios.  Plan is to start with Mac, then do Windows later (probably not worthing doing ChromeOS since it doesn't trigger browser zoom there today - better to go straight to pinch-zoom when it's ready).

When the browser gets an NOT_CONSUMED ACK back for a GesturePinchUpdate event, it can call into the browser zoom code (probably with a mechanism similar to the UnhandledWheelEvent).

Then in the cc input handler, we generate a synthetic ctrl+wheel event from trackpad GesturePinchUpdate events, and forward that to the renderer (when our existing hasWheelHandlers code says we should, so when there are no wheel handlers, we can trigger browser zoom without blocking on the renderer main thread).

Doing it this way is a little more involved than I was thinking of, but it's the right thing to do.  I'm still hopeful that I can get this all working at least on MacOS in time for M35.  Let me know if anyone is interested in picking up any of the sub-pieces here - I'm happy to carve it up.
Cc: ccameron@chromium.org stuartmorgan@chromium.org
Summary: Make trackpad pinch gestures send (overridable) wheel events (was: wire WheelEvent up to trackpad pinch gestures)
Project Member Comment 31 by bugdroid1@chromium.org, Mar 3 2014
------------------------------------------------------------------------
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
------------------------------------------------------------------------
Blockedon: chromium:111059
Apparently work to make ctrl+wheel was already going on in  issue 111059 .
I've got a change in progress to generate the GesturePinchUpdate events on Mac here: https://codereview.chromium.org/181723006/, but it still needs to have tests written (and a blink change landed).  I need to put this work on hold for a week or so to work on other urgent M35 items.
Project Member Comment 34 by bugdroid1@chromium.org, Mar 5 2014
The following revision refers to this bug:
    http://src.chromium.org/viewvc/blink?view=rev&rev=168482

------------------------------------------------------------------------
r168482 | rbyers@chromium.org | 2014-03-05T14:56:33.233870Z

Changed paths:
   M http://src.chromium.org/viewvc/blink/trunk/Source/web/WebInputEventFactoryMac.mm?r1=168482&r2=168481&pathrev=168482

Update WebInputEventFactory on Mac for pinch gesture support

WebInputEventFactory::gestureEvent was added a long time ago but is
not currently used.  Remove the existing unused code and update the
function to support creating GesturePinchUpdate events from Cocoa
NSEventTypeMagnify events.

BUG= 289887 

Review URL: https://codereview.chromium.org/184983003
------------------------------------------------------------------------
Blockedon: chromium:352474
Labels: -M-35 M-36
The next big step (the one mac-specific piece) is up for review here: https://codereview.chromium.org/181723006/

Unfortunately some urgent stuff came up and it looks like I won't get this all landed for M35, sorry!  This is getting very close though, so M36 should be no problem.
Project Member Comment 37 by bugdroid1@chromium.org, Mar 30 2014
------------------------------------------------------------------
r260452 | rbyers@chromium.org | 2014-03-30T17:37:29.555701Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/renderer_host/render_widget_host_delegate.cc?r1=260452&r2=260451&pathrev=260452
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/renderer_host/render_widget_host_delegate.h?r1=260452&r2=260451&pathrev=260452
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/renderer_host/render_widget_host_view_mac.mm?r1=260452&r2=260451&pathrev=260452
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/renderer_host/input/input_router_impl_unittest.cc?r1=260452&r2=260451&pathrev=260452
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/renderer_host/input/input_router_impl.cc?r1=260452&r2=260451&pathrev=260452
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/cocoa/browser_window_controller.h?r1=260452&r2=260451&pathrev=260452
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/renderer_host/render_widget_host_impl.cc?r1=260452&r2=260451&pathrev=260452
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/web_contents/web_contents_impl_unittest.cc?r1=260452&r2=260451&pathrev=260452
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/cocoa/browser_window_controller.mm?r1=260452&r2=260451&pathrev=260452
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/web_contents/web_contents_impl.cc?r1=260452&r2=260451&pathrev=260452
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/renderer_host/input/gesture_event_queue.h?r1=260452&r2=260451&pathrev=260452
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/web_contents/web_contents_impl.h?r1=260452&r2=260451&pathrev=260452

Handle mac trackpad zoom via GesturePinch events

Prior to this change, Mac handles pinch gestures directly in the UI layer (BrowserWindowController).  Here we instead have the RenderWidgetHost send GesturePinchUpdate events, and when those events go unhandled WebContentsImpl implements the browser zoom behavior (similar to how it does already for ctrl+mousewheel events on other platforms).

This lays the groundwork in the short term for giving the web page a chance to override the pinch behavior.  Longer term this will enable us to hook into the pinch-zoom codepath used for touchscreen so that we can get a similar effect (instead of just browser-zoom - which probably isn't really what the user wants when pinching).

The only observable behavior change in this CL is that pinching outside the content area (eg. in the tabstrip) no longer does anything.  It's not clear what the pinch origin should be in such a case, and it probably doesn't really make sense to try to handle it (pinching is supposed to zoom whatever is under the cursor).

This adds some basic unit test coverage for the pre-existing (but untested) logic for mapping pinch scales to zoom in/out actions.

Depends on blink CL: https://src.chromium.org/viewvc/blink?view=rev&revision=168482

BUG= 289887 

Review URL: https://codereview.chromium.org/181723006
-----------------------------------------------------------------
This is great! I've been searching for a uniform way of implementing pinch to zoom on web apps, nice to know we're pretty close!

So, to confirm, as a web developer, when this lands, to detect the pinch-to-zoom events will I need to check for the `ctrl` modifier key in the regular wheel events? Or will it set the `deltaZ` value? (or both?) With what precision of increments can I expect this event to fire? Will it be fired in "steps" like the current zoom implementation, or in a more continuous fashion like the other wheel events?

Can I also suggest the inclusion of a "ctrl+shift+wheel" or "ctrl+alt+wheel" event for trackpad rotation gestures? It would be really useful for drawing/painting applications, or for 3D model manipulation in WebGl apps.
Yes, you'll be able to check for 'ctrl'.  Try Firefox and IE on Windows today for an idea.  It'll be fired in a continuous fashion with a goal of making it easy to fluidly implement pan/drag/zoom UI.

Note however that there's still no way to tell if the user has a trackpad or mouse, so if you see only vertical mousewheel events it's not clear whether you'd want to zoom or pan.

Supporting rotation would be nice, but I think we'll need to get a standard API for that (maybe UIManipulationRequestEvent: http://www.w3.org/TR/indie-ui-events/#UIManipulationRequestEvent).  Just doing the ctrl thing is a big hack and really only acceptable because of precedent by other browsers (IE and Firefox on Windows).
Project Member Comment 40 by bugdroid1@chromium.org, Apr 28 2014
------------------------------------------------------------------
r266556 | rbyers@chromium.org | 2014-04-28T14:09:37.663657Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/web_contents/web_contents_impl_unittest.cc?r1=266556&r2=266555&pathrev=266556
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/web_contents/web_contents_impl.cc?r1=266556&r2=266555&pathrev=266556

Update trackpad pinch-zoom code for corrected scale semantics

In https://codereview.chromium.org/254783004 the semantics of the scale
parameter for GesturePinchUpdate on Mac is being corrected to be a scale
factor (1.0 no zoom) instead of a weird magnification value (where 0 means
no zoom).  This is important because GesturePinchUpdate events are
coalesced together by multipling (not adding) their scale values.

This CL updates the browser zoom logic to compensate for this change in
scale values.

BUG= 289887 

Review URL: https://codereview.chromium.org/255843004
-----------------------------------------------------------------
Project Member Comment 41 by bugdroid1@chromium.org, Apr 28 2014
Labels: merge-merged-git-svn
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/fb546cb67729f5755d1240434f006c85d060a562

commit fb546cb67729f5755d1240434f006c85d060a562
Author: rbyers@chromium.org <rbyers@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>
Date: Mon Apr 28 14:09:37 2014 +0000

Update trackpad pinch-zoom code for corrected scale semantics

In https://codereview.chromium.org/254783004 the semantics of the scale
parameter for GesturePinchUpdate on Mac is being corrected to be a scale
factor (1.0 no zoom) instead of a weird magnification value (where 0 means
no zoom).  This is important because GesturePinchUpdate events are
coalesced together by multipling (not adding) their scale values.

This CL updates the browser zoom logic to compensate for this change in
scale values.

BUG= 289887 

Review URL: https://codereview.chromium.org/255843004

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@266556 0039d316-1c4b-4281-b951-d872f2087c98


Project Member Comment 42 by bugdroid1@chromium.org, Apr 28 2014
The following revision refers to this bug:
  http://src.chromium.org/viewvc/blink?view=rev&rev=172763

------------------------------------------------------------------
r172763 | rbyers@chromium.org | 2014-04-28T14:39:41.097328Z

Changed paths:
   M http://src.chromium.org/viewvc/blink/trunk/Source/web/WebInputEventFactoryMac.mm?r1=172763&r2=172762&pathrev=172763

Fix pinchUpdate scale semantics

We expect the 'scale' value for GesturePinchUpdate to be a scale factor
(with 1.0 meaning no scaling).  The Cocoa API docs say you must add
1.0 to the magnification value to get the scale factor.

BUG= 289887 

Review URL: https://codereview.chromium.org/254783004
-----------------------------------------------------------------
Note that the ctrl+wheel behavior I was seeing on Windows is typically provided by the touchpad driver (there doesn't appear to be a standard gesture API for touchpads).  See http://msdn.microsoft.com/en-us/library/windows/hardware/dn614021(v=vs.85).aspx which says:
"When processing a two-finger zoom, the touchpad device should: Issue Ctrl+vertical wheel input when the user performs the zoom gesture."

This means, as of my ctrl+wheel fixes in M35, trackpad pinch-zoom will typically work as we've defined on Windows (but quality varies greatly by devices).  I've tested this with http://jsbin.com/qiyaseza/1 using a Lenovo UltaPoint device, and a Logitech T650 touchpad (with and without the Logictech smooth scrolling extension for Chrome) on Windows 8.  Unfortunately there does not appear to be a standard factor relating scales to deltaY values (but a formula like scale = 1 - wheelEvent.deltaY/100 seems OK in practice.

I'm working on a change that finishes adding the equivalent functionality for Mac: https://codereview.chromium.org/250923004/.
I've also tested that Bing maps and Google Maps work well with trackpad pinch-zoom in Chrome canary on Windows (with the two hardware configs above).

Project Member Comment 45 by bugdroid1@chromium.org, May 2 2014
------------------------------------------------------------------
r267822 | rbyers@chromium.org | 2014-05-02T17:00:00.699339Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/renderer_host/input/mock_input_ack_handler.h?r1=267822&r2=267821&pathrev=267822
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/common/input/web_input_event_traits.cc?r1=267822&r2=267821&pathrev=267822
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/renderer_host/input/input_router_impl_unittest.cc?r1=267822&r2=267821&pathrev=267822
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/renderer_host/render_widget_host_unittest.cc?r1=267822&r2=267821&pathrev=267822
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/renderer_host/input/input_router_impl.cc?r1=267822&r2=267821&pathrev=267822
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/renderer_host/input/gesture_event_queue_unittest.cc?r1=267822&r2=267821&pathrev=267822
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/renderer_host/input/input_router_impl.h?r1=267822&r2=267821&pathrev=267822
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/common/input/synthetic_web_input_event_builders.cc?r1=267822&r2=267821&pathrev=267822
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/renderer_host/input/mock_input_ack_handler.cc?r1=267822&r2=267821&pathrev=267822
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/renderer_host/input/touch_action_filter_unittest.cc?r1=267822&r2=267821&pathrev=267822
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/common/input/synthetic_web_input_event_builders.h?r1=267822&r2=267821&pathrev=267822
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/common/input/web_input_event_traits_unittest.cc?r1=267822&r2=267821&pathrev=267822

Synthesize ctrl-wheel events on touchpad pinch

On Windows, pinch gestures on a touchpad typically sends wheel events
with the ctrlKey modifier set.  This CL makes Chrome on Mac do the same
thing so that pages that are 'naturally zoomable' (eg. maps) get a
chance to override the pinch behavior before we use it to do browser
zoom.  Getting browser zoom on pinch is a long standing source of
confusion for users of Google Maps.  See http://goo.gl/84CTaJ for
discussion.

To be compatible with existing uses of wheel events, the deltaY value
in the wheel event is computed as -100*log(scale).  So zooming in 2x is
about -70 and zooming out 2x is 70. To compute a scale factor from this
value in JavaScript use 'Math.exp(-deltaY / 100)'.  See demo at
http://jsbin.com/qiyaseza/.

We expect to eventually want this change on ChromeOS as well (once
ChromeOS wires pinch up to pinch-zoom), and so this transformation
belongs in InputRouter.

The trickiest part of this change is handling the WheelEvent ACK
messages properly.  If the wheel was synthesized from a
GesturePinchUpdate, we need to convert the ACK back to the right type.
To do this I attach a 'synthesized_from_pinch' bit to each
WebWheelEvent in InputRouter's coalesced_mouse_wheel_events_ and to the
current_wheel_event_.  Then when I get a wheel ACK I use this bit on
current_wheel_event_ to decide how it should be handled.

This removes some old code which flushed any pending wheel events
whenever we got a non-wheel event.  Doing that causes us to ignore (or
possibly misattribute) the ACKs we'll eventually get back from the
renderer for these events.  This was probably already responsible for
some bugs with the Overscroll controller (which relies on
current_wheel_event representing THE event that we received an ACK for)
and  would be very problematic for the pinch-derived wheels where
(since the GestureEventQueue expects to reliably get an ack per event).
I tracked this code back to  http://crbug.com/154740  where it was added
to cope with the fact that we were discarding pending wheel events.  I
think a better fix for that is to just continue to queue and send wheel
events, even when there are other events happening (as we do for
interleaving touch and gesture events with other events).

BUG= 289887 

Review URL: https://codereview.chromium.org/250923004
-----------------------------------------------------------------
Project Member Comment 46 by bugdroid1@chromium.org, May 2 2014
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/621b3fe4c2e9821e396163f2e1cdfa2b3ffa320f

commit 621b3fe4c2e9821e396163f2e1cdfa2b3ffa320f
Author: rbyers@chromium.org <rbyers@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>
Date: Fri May 02 17:00:00 2014 +0000

Synthesize ctrl-wheel events on touchpad pinch

On Windows, pinch gestures on a touchpad typically sends wheel events
with the ctrlKey modifier set.  This CL makes Chrome on Mac do the same
thing so that pages that are 'naturally zoomable' (eg. maps) get a
chance to override the pinch behavior before we use it to do browser
zoom.  Getting browser zoom on pinch is a long standing source of
confusion for users of Google Maps.  See http://goo.gl/84CTaJ for
discussion.

To be compatible with existing uses of wheel events, the deltaY value
in the wheel event is computed as -100*log(scale).  So zooming in 2x is
about -70 and zooming out 2x is 70. To compute a scale factor from this
value in JavaScript use 'Math.exp(-deltaY / 100)'.  See demo at
http://jsbin.com/qiyaseza/.

We expect to eventually want this change on ChromeOS as well (once
ChromeOS wires pinch up to pinch-zoom), and so this transformation
belongs in InputRouter.

The trickiest part of this change is handling the WheelEvent ACK
messages properly.  If the wheel was synthesized from a
GesturePinchUpdate, we need to convert the ACK back to the right type.
To do this I attach a 'synthesized_from_pinch' bit to each
WebWheelEvent in InputRouter's coalesced_mouse_wheel_events_ and to the
current_wheel_event_.  Then when I get a wheel ACK I use this bit on
current_wheel_event_ to decide how it should be handled.

This removes some old code which flushed any pending wheel events
whenever we got a non-wheel event.  Doing that causes us to ignore (or
possibly misattribute) the ACKs we'll eventually get back from the
renderer for these events.  This was probably already responsible for
some bugs with the Overscroll controller (which relies on
current_wheel_event representing THE event that we received an ACK for)
and  would be very problematic for the pinch-derived wheels where
(since the GestureEventQueue expects to reliably get an ack per event).
I tracked this code back to  http://crbug.com/154740  where it was added
to cope with the fact that we were discarding pending wheel events.  I
think a better fix for that is to just continue to queue and send wheel
events, even when there are other events happening (as we do for
interleaving touch and gesture events with other events).

BUG= 289887 

Review URL: https://codereview.chromium.org/250923004

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@267822 0039d316-1c4b-4281-b951-d872f2087c98


Status: Fixed
Pinching on my macbook on Google maps now feels pretty good to me.  Let's consider this done and I'll file bugs for any follow-up issues once folks have had a chance to play with this.
Comment 48 by mpd@google.com, May 2 2014
Thanks, Rick!
Status: Verified
This does not work in packaged Chrome apps, mousewheel event is not fired at all when performing pinch gesture.
Comment 51 by mmi...@gmail.com, May 13 2015
Hm, yea. It is really hard to create a pinching event at the moment. I am using Mac OS X, 10.10.3, Chrome 42.0.2311.135, and testing with: https://jsfiddle.net/yoomwgLL/4/

So sometimes ctrl is set when I pinch, but most of the times nothing happens, and sometimes even just a normal wheel events happens.
Comment 52 by mmi...@gmail.com, May 13 2015
Correction. Pinch in with only two fingers work well. Pinch in with three is not recognized (fat fingers). Pinch out with two fingers is often recognized as only moving one finger and mouse moves. But that is probably Mac OS X gesture recognition issue.
Sign in to add a comment