Web-facing change PSA: trackpad pinch mousewheel events

[Rick Byers]

tl;dr: in crbug.com/289887 I propose changing Chromium on Windows and Mac to match IE and Firefox behavior when the user performs a pinch on the trackpad.  In particular, dispatching a mousewheel event with the 'ctrl' modifier set, and allowing websites to prevent the default behavior.

Motivation:

On Windows and Mac, Chromium responds to trackpad pinch events to trigger browser zoom. In "naturally zoomable" applications such as Google maps this is a regular source of complaints - causing confusion for the user when they get browser zoom (text getting bigger, images pixelated, etc.) instead of zooming the map.

Behavior in other browsers:

IE also triggers browser zoom by default on trackpad pinch, but it sends a mousewheel event with the 'ctrl' modifier present.  If this event is consumed (through preventDefault()) then the browser zoom behavior is suppressed.  The Google maps folks I've talked with say this behavior works well for them.  Firefox also sends ctrl mousewheel events on trackpad pinch, but requires an add-on to be installed to trigger browser zoom with pinch.

Presumably the argument for this behavior here is that since trackpads emulate mouse-based scrolling through mousewheel events, they can also reasonably emulate the typical pattern for mouse-based zooming (holding control while rolling the mouse wheel).

This solution isn't perfect (a new dedicated API would be ideal), but I believe that since it matches the behavior of the two other major desktop browsers and requires no new web standards work, it's the best pragmatic trade-off.  Any objection?

Thanks,

   Rick

[Nico Weber]

Yes, see bug?

 

Thanks,

   Rick

[Rick Byers]

Nico, I understand you'd rather see a new web API here rather than changing chromium to match firefox and IE's behavior.  I'd love to see that too, but I believe it would be a huge amount of work for relatively little gain - I don't think anyone is volunteering to drive that (unless you are?).  Perhaps UIManipulationRequestEvent will gain consensus and we can move to that at some point in the future, but it's likely to be a long time out still.

In the interim, is there really a good enough reason not to match IE and Firefox here?

Let's back up for a minute.  When there is a physical USB mouse, chromium directly handles Ctrl+Wheel to trigger browser zoom without giving websites a chance to override that behavior (no mousewheel event is sent).  Sending a ctrl+mousewheel event in this case (with preventDefault disabling the browser zoom behavior) seems completely reasonable (and consistent with mousewheel scroll behavior), right?  Of course it means that pages that eat mousewheel events will stop zooming on pinch, but this is consistent with our "content not chrome" principle - when the user is manipulating the web contents, the contents should have primary say (just like a page can override the handling of the zoom keyboard shortcuts - there's always the chrome UI to fall back upon).

The only remaining question is to what extent gestures on a trackpad emulate a mouse.  If we're already sending 'mousewheel' events for two finger panning on the trackpad (which is already a "lie" with a strict interpretation of the mousewheel API), is sending ctrl+mousewheel for two-finger pinching sufficiently worse that we should leave the maps problem unsolved (such that maps users on IE and Firefox have a better experience than those on Chrome)?  To me it's just part of mapping trackpad gestures to their most natural equivalent in the APIs we have for other hardware.  Web developers already have to be prepared for (and perhaps even expect) this interpretation from the other 2 major browsers on Windows.

Adam, any input?  Perhaps we should go through the blink intent-to-ship process for this (even though it's not technically covered since it's not implemented in blink)?  It sounds like it's ultimately API compat risk that we're concerned with here.

Rick

[Adam Barth]

On Thu, Jan 16, 2014 at 9:40 AM, Rick Byers <rby...@chromium.org> wrote:

Nico, I understand you'd rather see a new web API here rather than changing chromium to match firefox and IE's behavior.  I'd love to see that too, but I believe it would be a huge amount of work for relatively little gain - I don't think anyone is volunteering to drive that (unless you are?).  Perhaps UIManipulationRequestEvent will gain consensus and we can move to that at some point in the future, but it's likely to be a long time out still.

In the interim, is there really a good enough reason not to match IE and Firefox here?

Let's back up for a minute.  When there is a physical USB mouse, chromium directly handles Ctrl+Wheel to trigger browser zoom without giving websites a chance to override that behavior (no mousewheel event is sent).  Sending a ctrl+mousewheel event in this case (with preventDefault disabling the browser zoom behavior) seems completely reasonable (and consistent with mousewheel scroll behavior), right?  Of course it means that pages that eat mousewheel events will stop zooming on pinch, but this is consistent with our "content not chrome" principle - when the user is manipulating the web contents, the contents should have primary say (just like a page can override the handling of the zoom keyboard shortcuts - there's always the chrome UI to fall back upon).

The only remaining question is to what extent gestures on a trackpad emulate a mouse.  If we're already sending 'mousewheel' events for two finger panning on the trackpad (which is already a "lie" with a strict interpretation of the mousewheel API), is sending ctrl+mousewheel for two-finger pinching sufficiently worse that we should leave the maps problem unsolved (such that maps users on IE and Firefox have a better experience than those on Chrome)?  To me it's just part of mapping trackpad gestures to their most natural equivalent in the APIs we have for other hardware.  Web developers already have to be prepared for (and perhaps even expect) this interpretation from the other 2 major browsers on Windows.

Adam, any input?  Perhaps we should go through the blink intent-to-ship process for this (even though it's not technically covered since it's not implemented in blink)?  It sounds like it's ultimately API compat risk that we're concerned with here.

I'm not sure we need to go through a formal process.  Mostly it just sounds like we ought to talk with Nico and make sure we've understood his point of view.  From reading this thread and the bug, it seems like there are two issues:

1) Chrome doesn't behave the same way as other browsers.

2) Chrome doesn't support high-fidelity trackpad gestures.

Both problems seems worth solving.  My understanding of Nico's concern is that he thinks we should resolve (2) first.  Given that we want to take a standards-based approach when introducing new APIs, the lead time on (2) is probably significant, especially given the IPR concerns that gave rise to the separate W3C Pointer Events Working Group.  A more pragmatic approach is to make the maps team happy by resolving (1) first.  That certainly doesn't preclude resolving (2) in the future.

Adam

[Nico Weber]

On Thu, Jan 16, 2014 at 10:46 AM, Adam Barth <aba...@chromium.org> wrote:

On Thu, Jan 16, 2014 at 9:40 AM, Rick Byers <rby...@chromium.org> wrote:

Nico, I understand you'd rather see a new web API here rather than changing chromium to match firefox and IE's behavior.  I'd love to see that too, but I believe it would be a huge amount of work for relatively little gain - I don't think anyone is volunteering to drive that (unless you are?).  Perhaps UIManipulationRequestEvent will gain consensus and we can move to that at some point in the future, but it's likely to be a long time out still.

In the interim, is there really a good enough reason not to match IE and Firefox here?

Let's back up for a minute.  When there is a physical USB mouse, chromium directly handles Ctrl+Wheel to trigger browser zoom without giving websites a chance to override that behavior (no mousewheel event is sent).  Sending a ctrl+mousewheel event in this case (with preventDefault disabling the browser zoom behavior) seems completely reasonable (and consistent with mousewheel scroll behavior), right?  Of course it means that pages that eat mousewheel events will stop zooming on pinch, but this is consistent with our "content not chrome" principle - when the user is manipulating the web contents, the contents should have primary say (just like a page can override the handling of the zoom keyboard shortcuts - there's always the chrome UI to fall back upon).

The only remaining question is to what extent gestures on a trackpad emulate a mouse.  If we're already sending 'mousewheel' events for two finger panning on the trackpad (which is already a "lie" with a strict interpretation of the mousewheel API), is sending ctrl+mousewheel for two-finger pinching sufficiently worse that we should leave the maps problem unsolved (such that maps users on IE and Firefox have a better experience than those on Chrome)?  To me it's just part of mapping trackpad gestures to their most natural equivalent in the APIs we have for other hardware.  Web developers already have to be prepared for (and perhaps even expect) this interpretation from the other 2 major browsers on Windows.

Adam, any input?  Perhaps we should go through the blink intent-to-ship process for this (even though it's not technically covered since it's not implemented in blink)?  It sounds like it's ultimately API compat risk that we're concerned with here.

I'm not sure we need to go through a formal process.  Mostly it just sounds like we ought to talk with Nico and make sure we've understood his point of view.  From reading this thread and the bug, it seems like there are two issues:

1) Chrome doesn't behave the same way as other browsers.

2) Chrome doesn't support high-fidelity trackpad gestures.

Both problems seems worth solving.  My understanding of Nico's concern is that he thinks we should resolve (2) first.  Given that we want to take a standards-based approach when introducing new APIs, the lead time on (2) is probably significant, especially given the IPR concerns that gave rise to the separate W3C Pointer Events Working Group.  A more pragmatic approach is to make the maps team happy by resolving (1) first.  That certainly doesn't preclude resolving (2) in the future.

Ok.

[Rick Byers]

Great, thanks guys!