Zoom in/out is the same as the rest of the web browser - ctrl + - and ctrl + =. Any suggestions for fit-to-{page,width} that doesn't conflict with other browser shortcut keys?

ctrl+\ and ctrl+; don't seem to be taken, and either of those would go pretty well with ctrl+[ and ctrl+] for rotation.

How about just mapping the ctrl+\ (not taken according to ctrl+alt+? on my Chromebook) to a toggle between fit-to-{page,width} ? That way it maps 1:1 with the zoom toggle button.

+wjmaclean for all zoomy things.

A single key to toggle seems ideal, since that's what the on-screen button does to.

I can pretend to write JS: https://codereview.chromium.org/2283803003

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

commit b9e8d9e97bd881fff98082b4490483926fa84aed
Author: thestig <thestig@chromium.org>
Date: Wed Sep 07 07:52:44 2016

PDF: Add shortcut to toggle fit-to-{page,width}.

ctrl + \

BUG= 636515 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

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

[modify] https://crrev.com/b9e8d9e97bd881fff98082b4490483926fa84aed/chrome/browser/resources/pdf/elements/viewer-zoom-toolbar/viewer-zoom-toolbar.js
[modify] https://crrev.com/b9e8d9e97bd881fff98082b4490483926fa84aed/chrome/browser/resources/pdf/pdf.js
[modify] https://crrev.com/b9e8d9e97bd881fff98082b4490483926fa84aed/chrome/test/data/pdf/material_elements_test.js

I think we should not use event.keyCode attribute to detect keys as people have issues on AZERTY keyboards. See comment #1 at https://plus.google.com/+FrancoisBeaufort/posts/VPCSTsUjDK6

I would recommend using new "code" Attribute for that. See https://developers.google.com/web/updates/2016/04/keyboardevent-keys-codes?hl=en and https://w3c.github.io/uievents/tools/key-event-viewer.html

fbeaufort: Thanks for the tip. I'll switch chrome/browser/resources/pdf/ to the "code" attribute. Would you be able to help test / review the CL?

It does appear "\" may not be the best choice for several non-US layouts.

Even the "-+[]" grouping is bad for AZERTY. Not sure if AZERTY keyboard users are just used to it, or if there is some keyboard layout specific adjustments in software somewhere.

Oh, event.code is funky. If I switch to it:
- Does that mean '^' and '$' on a French AZERTY keyboard will map to '[' and ']' respectively?
- Isn't '\' still in a weird spot on keyboards with a double row enter key?
- Won't virtual keyboards stop working?
- It breaks Chrome in VNC for me as described below.

Right now I'm accessing my workstation over VNC. In VNC:
- key '[' is code 'KeyY'
- key ']' is code 'KeyU'
- '\' is 'ControlLeft'

Many other keys are mapped funny as well. I know QEMU also does not work right inside VNC for me. There, I have to run "qemu -k en-us" for it to work. The QEMU manpage mentions this is necessary for VNC. Maybe we should open a new bug...

https://codereview.chromium.org/2358553002 to switch to the "code" attribute. Probably a work in progress given the above.

I've switched to french (AZERTY) Mac keyboard and I can't even find the \ key on it... We should definitely try to find something better there that works for everyone.