Issue metadata
Sign in to add a comment
|
Caps lock is behaving like shift button
Reported by
tolive...@keep.pt,
Jun 14 2018
|
||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3457.2 Safari/537.36 Steps to reproduce the problem: 1. Turn on caps lock 2. Open a new tab from keyboard (cmd + t) 1. Turn on caps lock 2. Press cmd + b What is the expected behavior? To open a new tab Default cmd+B behaviour What went wrong? It opens the last tab (equivalent to cmd+shift+t) It shows bookmark bar (equivalent to cmd+shift+b) Did this work before? Yes Chrome version: 69.0.3457.2 Channel: canary OS Version: OS X 10.12.6 Flash Version:
,
Jun 14 2018
,
Jun 14 2018
What type of keyboard and input method [dvorak maybe?] are you using.
,
Jun 15 2018
It's a normal macbook pro keyboard. QWERTY layout, with pt_PT locale.
,
Jun 15 2018
I can repro by switching to polish keyboard.
,
Jun 15 2018
With caps lock turned on, pressing cmd + t EN keyboard has: NSEvent: type=KeyDown loc=(258.996,712) time=367552.2 flags=0x110108 win=0x7fb389a2d310 winNum=27444 ctxt=0x0 chars="t" unmodchars="t" repeat=0 keyCode=17 PT keyboard has: event: NSEvent: type=KeyDown loc=(543.996,863) time=367419.4 flags=0x110108 win=0x7feec7771630 winNum=27439 ctxt=0x0 chars="T" unmodchars="t" repeat=0 keyCode=17 dvorak: event: NSEvent: type=KeyDown loc=(198.996,682) time=367790.5 flags=0x110108 win=0x7fa2e3334470 winNum=27454 ctxt=0x0 chars="y" unmodchars="y" repeat=0 keyCode=17 dvorak + qwerty: event: NSEvent: type=KeyDown loc=(264,303) time=367826.1 flags=0x110108 win=0x7fa2e3334470 winNum=27454 ctxt=0x0 chars="t" unmodchars="y" repeat=0 keyCode=17
,
Jun 15 2018
,
Jun 18 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/767446e00e56d703a9461ee5cae2a64d6c6281cb commit 767446e00e56d703a9461ee5cae2a64d6c6281cb Author: erikchen <erikchen@chromium.org> Date: Mon Jun 18 20:58:30 2018 macOS: Fix keyEquivalents on PT keyboard layout. The only layout that should use -[NSEvent characters] to match keyEquivalents rather than -[NSEvent charactersIgnoringModifiers] is DVORAK-QWERTY. This CL updates the logic in NSMenuItem(ChromeAdditions) to make this check. Bug: 852820 Change-Id: Ib3f63bfadfd10ec5259324b2d7d52510997f7a98 Reviewed-on: https://chromium-review.googlesource.com/1103121 Reviewed-by: Nico Weber <thakis@chromium.org> Commit-Queue: Erik Chen <erikchen@chromium.org> Cr-Commit-Position: refs/heads/master@{#568158} [modify] https://crrev.com/767446e00e56d703a9461ee5cae2a64d6c6281cb/chrome/browser/ui/cocoa/nsmenuitem_additions.h [modify] https://crrev.com/767446e00e56d703a9461ee5cae2a64d6c6281cb/chrome/browser/ui/cocoa/nsmenuitem_additions.mm [modify] https://crrev.com/767446e00e56d703a9461ee5cae2a64d6c6281cb/chrome/browser/ui/cocoa/nsmenuitem_additions_unittest.mm
,
Jun 18 2018
|
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by rsesek@chromium.org
, Jun 14 2018