There's also bug 881827 for other keys that do not work.

I tried with 10.13 and Chrome 69 and I'm not seeing this.

Can you try this set of actions? Top menu bar -> Chrome -> About Google Chrome

This opens the about page and triggers an update check. Chrome should update to version 69. Then can you restart Chrome, and see if the issue still persists?

It turns out I can't reproduce with Chrome 68 either, so maybe this issue requires macOS 10.12 to reproduce, or something else.

simonrob@Thanks for the issue...
Unable to reproduce the on reported chrome 68.0.3440.106 and latest chrome 69.0.3497.81 using Mac 10.13.6. Attaching screen-cast for reference.
Steps:
-----
1. Launched reported chrome
2. Opened three windows along with PDF 
3. Clicked on " cmd + ` " 
As we are observed that cmd + ` switches between windows

@Reporter: Could you please upgrade to latest chrome stable 69.0.3497.81, you can download latest chrome builds here:
" https://www.chromium.org/getting-involved/dev-channel ". Let us know whether issue still persists.

Thanks.!

Deleted: 882888.mp4 2.3 MB

	882888.mp4 2.3 MB View Download

One possible reason: I have set a keyboard layout where backtick is mapped to a different key.

With the default keyboard layout the problem doesn't happen, regardless of Chrome version. However, if I switch to another inbuilt layout where backtick is not in the default position then the same issue occurs.

For example: switch to Spanish, and try cmd + ` (use ] for backtick on a Spanish keyboard layout)

Thank you for providing more feedback. Adding the requester to the cc list.

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

That would explain it. Another question - is this a US keyboard with the Spanish layout, or is the physical keyboard non-US?

I'm not totally sure, as I don't have a US version to-hand. According to Apple's guide at https://support.apple.com/en-gb/HT201794, the keyboard I have is the one listed as "English, Great Britain - (B)". If the US one is the one that's listed as just "English", then yes, the layout is different. The normal keyboard layout I use puts backtick where it is on the English one, however.

Out of interest, I tested for this on a really old laptop with the same keyboard and the same remapping, and a very old version of Chrome (49.0.2623.112 (64-bit)). This older setup does not have the issue.

Thanks for the info. Hopefully whoever ends up looking into this issue can just change the layout in software, and won't require a region-specific keyboard to reproduce the issue.

+lgrey for Mac triage.

erikchen@ is this a dupe of  Issue 811921 ?

Not sure -- if this works on ToT, then this is likely a dupe. If it doesn't work on ToT, then it's different.

Bug reporter: Can you try installing Chrome Canary to see if this bug exists there? It may already be fixed in an upcoming release.

I installed Chrome Canary (71.0.3550.3 (Official Build) canary (64-bit)). The issue still occurs.

Note: it must be the PDF that is focused for this issue to happen, not the Omnibox or find panel.

Unable to reproduce this issue on Mac 10.13.6 with chrome #68.0.3440.106, #71.0.3551.0 as steps mentioned in the comment #0

Attaching the screen-cast for reference.

Since TE doesn't able to repro the issue adding TE-NeedsTriageHelp label for further triage from PDF dev team

Deleted: 882888.mp4 1.5 MB

	882888.mp4 1.5 MB View Download

kkaluri@ - please note that when I reported this I didn't initially realise that an important factor was the keyboard layout. See comment 7.

To reproduce a similar setup: go to System Preferences > Keyboard > Input Sources and add Spanish. Make sure to actually switch to this layout using the icon in the menu bar. Check that ] produces a `. Then use cmd + ] to switch to/from PDFs.

Looks like we're not triggering the code added to address  Issue 145062 .

That makes sense, because the keycode doesn't match. What doesn't make sense to me is the event looks like this:
NSEvent: type=KeyDown loc=(1341.86,413.617) time=1220471.6 flags=0x100108 win=0x17a01a1a0 winNum=27332 ctxt=0x0 chars="" unmodchars="" repeat=0 keyCode=30

Note empty chars and unmodchars (this isn't a description display issue, both characters and charactersIgnoringModifiers are empty string).

For anyone more familiar with alternate layout event handling: is there some other way we can pull the real characters? If so, we can change how we check the system keys to account for it. If not, I'm not sure what we can do here.

Finally got around to try this. It's each to reproduce. This regressed a while back. I tried r500000 and r540000 and both had this issue, whereas r400000 did not. Will bisect...

And with 6 minutes of bisecting and analysis, we arrive at https://chromium.googlesource.com/chromium/src/+log/964e8be1..f34d56e2, so I bet this is r489156.

Although r489156 looks suspicious :), it only touches devtools code, and the repro doesn't involve DevTools. Seems unlikely to be the culprit.

Maybe https://chromium.googlesource.com/chromium/src/+/569c81ec7c8d952286fa06725929041a51111408 is related?

Doh, I didn't look hard enough. Good thing nobody took my bet.

This is still broken, and I find it happens with an external ISO keyboard (UK layout) as well.

dtapuska: Can you take a look?

Navid is handling input these days.

benl@ what is the Chrome version you are testing? It should be fixed in Chrome 72 (currently in beta). Can you try with the latest version and see whether you see this issue or not.

I still see this on 73.0.3664.0 Canary.