kuscher@ any suggestions on an alternative mapping that would work on a german keyboard?

Alt + left/right key would do it!
If that is already taken, Alt + ö/ä could be used instead.

Would Alt+8 work since that is where the ] resides as a secondary mapping? Or would there another key be needed to get to that?

Alt + any number opens the window with that number on the taskbar, so this alternative would not work.

Ok, so the alternatives I can see

Alt + ö or ä
Alt + , or .
Alt + Shift + 8 or 9
Alt Gr + 8 or 9 (which maps to [ and ])

@Joshua, does alt gr 8 or 9 do anything? I am German but couldn't find a German keyboard quickly so if you know, that would be great.

+Tom as well to drive the implementation of this

Alt Gr + 8/9 does not do anything else, but if I currently were in a text field and wanted to dock a window, I'd just type [ or ].

Alt + Shift + 8/9 would be kind of complicated.

I guess Alt + ö/ä would work on any german keyboard, but I don't know if those keys are missing on other keyboards that also don't contain the [ ] keys. Danish for example has the Æ and Ø keys there.

What about the left and right arrow keys? Ctrl + left/right would be most intuitive and does not do anything else (Alt + left/right switches pages in the browser history). 

Ctrl+left/right currently jump to the next/previous word.

My preference would be Alt+Shift+8/9 since that keeps the mapping between left/right brace and left/right docking and will be shared across other keyboards, eg. Danish. It is an extra key but making it easier to remember seems worth the tradeoff.

@afakhry could you add this?

 Issue 670143  has been merged into this issue.

Re#7: tbuckley, are you requesting that we deprecate Alt+[, Alt+] and replace with Alt+Shift+8/9?

We don't specify different shortcuts based on the keyboard layout.

I tried with a Norwegian keyboard layout. AltGr+9 produces ] in textfields, however we are still getting VKEY_9 in the keycode of the event instead of VK_OEM_6 (close bracket). Our keyboard shortcuts are VKEY based.

Speaking offline with kpschoedel, it seems that someone has to test on Windows with a Norwegian keyboard layout to see what keycode Windows produces. If Windows produces VK_OEM_6, then this is a bug we need to fix. Otherwise, we'd have to workaround this issue.

shuchen, can you please investigate this issue?

Tested on Win7, the AltGr+9 on Norwegian layout produces VKEY_9 instead of VKEY_OEM_6.

This is a rather common issue cross all platforms.

e.g.
on MacOS+US-layout, Cmd+Shift+/ opens the Help menu;
on MacOS+NO-layout, either Cmd+Shift+/, Cmd+Shift+- or Cmd+- cannot open the Help menu.

on Win7+US-layout, Ctrl+- zooms in the web page;
on Win7+FR-layout, either Ctrl+- or Ctrl+6 cannot zoom in the web page.

To solve this issue, I think the accelerator table/controller should be smart enough to leverage not only KeyEvent::key_code() but also KeyEvent::GetDomKey() & KeyEvent::code().

#12 I very much agree with shuchen@ here. Chrome was originally written for Windows but that was a long time ago and Windows-emulation VKEY codes are not ideal for a cross-platform cross-language project. Changing this will be a *lot* of work, though. 

Wow, that's going to be a *HUGE* change! But it will fix a lot of the shortcut-related bugs I receive all the time from non-US layout users (example:  Issue 630878 ).

+abodenha for prioritization.

 Issue 630878  has been merged into this issue.

See the many issues blocking Issue 300469.

Re#12:

> should be smart enough to leverage not only KeyEvent::key_code() but also
> KeyEvent::GetDomKey() & KeyEvent::code().

Shuchen, why would we want to use all three together and not only one of them?

I did an experiment with the Norwegian layout, and it seems GetDomKey() is what we should use?

On a Norwegian layout:
AltGr+9 ---> "]"
key_code() is VKEY_9.
DomKeyToKeyString(GetDomKey()) is "]".
DomCodeToCodeString(code()) is "Digit9".

Can you please explain a bit more?

#17 The problem with using DomKey alone is that all the letter-based shortcuts wouldn't be available on non-Latin keyboards (e.g. Control+VKEY_A is Control+DomKey::'Ф' in Russian).

Similarly the problem with DomCode alone is Latin layouts with different letter arrangements (e.g. Control+VKEY_A is Control+DomCode::'q' in French).

I complain a lot about VKEY codes but they actually work well for Latin-letter shortcuts. A rule for using uievents-encodings for accelerators would have to be similar to the simple case for VKEYs, i.e. |DomKey if it's a printable 7-bit ASCII character else DomCode|. But it could do that without the huge VKEY tables because the goal would be to be simply evident to the user, rather than to exactly emulate historic Windows layouts.

OK, I think I see a way to make this work across languages without having to rewrite *all* the shortcut handling. Straw-man proposal: https://docs.google.com/a/chromium.org/document/d/1Suk7gYF0mFvIS_i6IjY9qwXReRHfrzMbTbUcpgba844/edit?usp=sharing

@kpschoedel thanks for putting that proposal together! What's the next step for it?

Also, could you point me to where existing shortcuts are defined so we can determine which ones would need to change? Thanks!

#20 Next step would be for someone familiar with how shortcuts are matched to consider whether this would work. (I worked a lot on the event-producing side when I was on Chrome, but rarely touched event-consuming parts.) I'll add some further notes to the doc.

I *think* most/all shortcuts are instances of https://cs.chromium.org/chromium/src/ui/base/accelerators/accelerator.h?q=ui::Accelerator

Please prioritize this. It was targeted for M58 but hasn't had any action in more than a year.

We need manager and PM to prioritize this.
Solution suggested in Comment 19 by kpschoedel@ looks like a good start.

I feel like we have a history of putting bandaids on keyboard issues rather than taking a step back and investing in larger refactors to address the sorts of issues that keep coming up.  That's often the right move as it allows us to get fixes out to address user pain quickly.

How would folks classify the solution in 19?  Is it a general improvement that will lead to less pain for everyone in the long run? If so, let's do it.

I think the solution in #19 is the right way to solve the pain for the long run.
But I'm not sure about the effort of implementing the solution.

This bug has an owner, thus, it's been triaged. Changing status to "assigned".

 Issue 816428  has been merged into this issue.