Removing comment in description about all sites being affected. That was a different issue unrelated to mac. Dropping the priority back to match that of the original bug accordingly.
Adding note about the use of the touchpad to the description.

Description is pdf zoom, not browser zoom.

I have a fix for this, and will put up a CL tomorrow.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1bbc9fc2b43ec7b02f5f781ffb70675c5def4220

commit 1bbc9fc2b43ec7b02f5f781ffb70675c5def4220
Author: wjmaclean <wjmaclean@chromium.org>
Date: Fri Mar 10 19:12:36 2017

Browser plugin should never handle MouseWheels.

Now that we do direct routing of MouseWheel events to guests,
BrowserPlugin should (1) never mark a MouseWheel as handled (this may
cancel GesturePinch on Mac), and (2) it should never forward the
MouseWheel to the guest. This CL implements this policy.

BUG= 695907 

Review-Url: https://codereview.chromium.org/2745783002
Cr-Commit-Position: refs/heads/master@{#456125}

[modify] https://crrev.com/1bbc9fc2b43ec7b02f5f781ffb70675c5def4220/content/renderer/browser_plugin/browser_plugin.cc

Your change meets the bar and is auto-approved for M58. Please go ahead and merge the CL to branch 3029 manually. Please contact milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), bhthompson@(cros), govind@(desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Please merge your change to M58 branch 3029 before 5:00 PM PT, Monday (03/13/17) so we can take it in for next week dev release. Thank you!

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/27a8e4ccda5f7215f452891b5f66f167cbdc4004

commit 27a8e4ccda5f7215f452891b5f66f167cbdc4004
Author: W. James MacLean <wjmaclean@chromium.org>
Date: Mon Mar 13 13:59:08 2017

Browser plugin should never handle MouseWheels.

Now that we do direct routing of MouseWheel events to guests,
BrowserPlugin should (1) never mark a MouseWheel as handled (this may
cancel GesturePinch on Mac), and (2) it should never forward the
MouseWheel to the guest. This CL implements this policy.

BUG= 695907 

Review-Url: https://codereview.chromium.org/2745783002
Cr-Commit-Position: refs/heads/master@{#456125}
(cherry picked from commit 1bbc9fc2b43ec7b02f5f781ffb70675c5def4220)

Review-Url: https://codereview.chromium.org/2745153002 .
Cr-Commit-Position: refs/branch-heads/3029@{#147}
Cr-Branched-From: 939b32ee5ba05c396eef3fd992822fcca9a2e262-refs/heads/master@{#454471}

[modify] https://crrev.com/27a8e4ccda5f7215f452891b5f66f167cbdc4004/content/renderer/browser_plugin/browser_plugin.cc

Tested the issue on Mac-10.12.2 using chrome version#58.0.3029.19 with the steps mentioned in comment#0.
Observed that the fix is working as expected. Hence adding TE-Verified labels.
Please find the attached screen cast for the same.

Thanks!!

Deleted: 695907.mov 24.2 MB

695907.mov 24.2 MB Download

 Issue 707757  has been merged into this issue.

Using Chrome 60 beta, this looks really far from perfect.

As mentioned c#0, please have a look at Safari. It is noticeable even on the clip uploaded above, obviously it should be zoomed to the place mouse pointing at not at the left side of a pdf, there is a Ctrl++ for that and pinch-to-zoom is not meant to be like this.

The PDF is pixelated and pdf toolbar disappears after zooming in, are you sure this shouldn't be solved on pdfium side? It seems Chromium completely misses the point of zooming on PDF. 

Deleted: Screen Shot 2017-06-21 at 11.22.15 PM.png 213 KB

	Screen Shot 2017-06-21 at 11.22.15 PM.png 213 KB View Download

The PDF toolbar is designed to auto-hide itself. You have to move the mouse around to get the toolbar to re-display.

I believe the zooming based off the top-left of the page is to match how chrome/blink handling pinch zoom.

> The PDF toolbar is designed to auto-hide itself. You have to move the mouse around to get the toolbar to re-display.

This is not the case with pinch-to-zoom (moving two fingers on touchpad on opposite direction) page, it doesn't show because the way this implemented originally doesn't seem right (It seems this zooms on entire the page not just the place pdf is there)

> I believe the zooming based off the top-left of the page is to match how chrome/blink handling pinch zoom.

Pinch-to-zoom on normal pages works much better than this AFAICT.

Deleted: Screen Shot 2017-06-22 at 12.08.46 AM.png 34.4 KB

	Screen Shot 2017-06-22 at 12.08.46 AM.png 34.4 KB View Download

This looks like something has regressed since the original work ... it would be good to test this against the M58 version mentioned in Comment #12. If it is indeed working properly in that version, then this new behaviour should be in a new bug report.

The new behaviour looks like GesturePinch events are being forwarded to the GuestView when they shouldn't be.

I just watched the video, and indeed the PZ is not entirely as desired, though at present it may be the best we can do for Mac. Mac PZ directly sends GesturePinch events, but these have no real meaning to the PDF viewer. On Aura we fix this by cancelling the touch events before the GesturePinch events can even be created.

Really what we should do here is intercept the mouse wheel events, cancel them, but use the information in them to drive the PDF's viewer own internal zooming code. mcnee@ is the expert w.r.t. this system.

Right. This behaviour is the result of the pdf viewer being unaware of pinch zooming via the trackpad. The browser just zooms the entire UI, hence the controls being zoomed off screen and the pdf content not rerastering. This is the behaviour that touchscreen pinch zooming had before we had the viewer override the native pinch zoom.

Since the mac touchpad does not produce touch events that we can use to prevent native pinch zoom, additional work is needed to hook up the mac touchpad pinches to the viewer's internal pinch zooming mechanism.
See  crbug.com/715662 

In the case of Mac pinch, I think RenderWidgetHostViewMac *directly* sends GesturePinchX events to the top-level frame ... in that frame's renderer synthetic trackpad wheels are created to allow JS to cancel/override the pinch behaviour.

So what we would need to do is:
i) detect the tab is showing a PDF, then
ii) only in that case forward the GesturePinchX events to the guest's frame/view, and 
iii) have JS in the PDF viewer detect the synthetic trackpad wheels, mark them as handled (prevent-default) and use their data to do the proper UI zooming just like we do for Aura.

No a trivial task, and there may be some issues about treating event forwarding differently for PDFs that will need to be discussed.

@wjmaclean: Is it possible to put your workaround/roadmap on a trackable bug or reopen this as its original intention or  crbug.com/715662  looks enough?

Regarding treating PDFs differently, I tried out a wheel listener inside an out of process iframe and it also had this problem. With non-OOPIF, the handler sees the wheel events and can prevent default to prevent browser pinch zoom. With OOPIF, the handler doesn't see them and the browser zooms.

Kevin has created a new bug at https://bugs.chromium.org/p/chromium/issues/detail?id=739213, and I've linked a patch from there that will route the Mac GesturePinch events to the guest view (or OOPIF subframe for that matter). Not sure yet what tests it might break, but it's underway at least.