guanrunjie@ Thanks for the issue...

Unable to reproduce the issue on reported chrome version 69.0.3497.100 using Mac 10.13.6. Attaching screen-cast for reference.
Steps: 
---------
1. Launched reported chrome 
2. Opened Mac settings > Keyboard -> Shortcuts -> App Shortcuts > Clicked on + and added shortcut Ctlr + A 
3. Navigated to some sites as per screencast and clicked on Ctrl + A
As we are observed that text selected

@Reporter: Could you please check the attached screen cast and please let us know if anything missed from our end and verify this issue with New profile. Let us know whether issue still persists

Thanks.!

Deleted: 890418.mp4 1.4 MB

	890418.mp4 1.4 MB View Download

Probably related to  issue 882166 .

Erik, you've made shortcut changes.

To: phanindra.mandapaka@chromium.org

Thanks for the video. However in the video attached, the assigned shortcut is actually cmd+A (⌘A), not ctrl+A (⌃A). 

 Issue 882166  is caused by a bug where MacViews is failing to process the Paste without style command.

This issue is likely caused by the fact that Views makes the assumption that hotkeys are fixed and not configurable -- and those are hardcoded into the binary. 

e.g.
https://cs.chromium.org/chromium/src/ui/views/controls/textfield/textfield.cc?type=cs&q=select_all+file:views&sq=package:chromium&g=0&l=114

Over to Ellyjones for triage

Icky. I'll take a peek.

Able to reproduce the issue on chrome version 69.0.3497.100 and latest chrome 71.0.3569.0 using Mac OS 10.13.6. Below is the bisect information for same.

Bisect Info:
================
Good build: 69.0.3489.0
Bad build: 69.0.3491.0
You are probably looking for a change made after 574627 (known good), but no later than 574628 (first known bad).

CHANGELOG URL:
https://chromium.googlesource.com/chromium/src/+log/176a3a3154870bc3e0722934c03d6dc3b5dae748..3e0fccc527819cb8e09682bc280fb35d4b3fafdd

Suspect: https://chromium.googlesource.com/chromium/src/+/3e0fccc527819cb8e09682bc280fb35d4b3fafdd

Reviewed-on: https://chromium-review.googlesource.com/1134203

erikchen@chromium.org and ellyjones@chromium.org : Please confirm the issue and help in re-assigning if it is not related to your change.Adding RBS label for M-70 feel free to change it if not required.

Thanks!

We can't block M70 stable on this.

We received feedback reports that system shortcuts are also failing if you are using a non-EN keyboard.

Example reports:
https://listnr.corp.google.com/report/85693132950
https://listnr.corp.google.com/report/85700029108
https://listnr.corp.google.com/report/85693132950
https://listnr.corp.google.com/report/85701373427

Hey all, do we have any update? I can't update my Chrome because of this :'(

I haven't yet had time to work on this. It will be a not-small amount of work unfortunately. I will target a fix at M72.

*** Mass UI Triage ***

Able to reproduce this issue on Mac with chrome #72.0.3610.0

Note: Issue is not applicable to Windows & Linux

This won't get into M72 either. M73 or bust!

Hey devs, any update? Are we still expecting it in M73? I've been using v69 for almost half a year now :) Thanks

I just looked at this again and I'm not sure if this bug is still present. If I do this:

1) System Preferences > Keyboard > Shortcuts > App Shortcuts
2) Click '+' and add ^A as a shortcut for "Select All"

then:

a) Ctrl-a selects all text in the omnibox
b) Cmd-a selects all text in the omnibox
c) Ctrl-a selects all text in another Views textfield (I used the bookmark star bubble's name field)
d) Cmd-a selects all text in that textfield too

In *web* text fields, none of these bindings work properly, of course - but that's the same in Safari.

The code erikchen@ linked in Textfield is clearly doing the wrong thing, but visually it is clear that the assigned shortcut is being dispatched via the menus instead of Textfield's input code. To rule out that the Textfield code is somehow being reached anyway, I also tried assigning Ctrl-B to "Select All" and that still works.

Right now, I think that the custom hotkey is getting dispatched via BridgedContentView, not Textfield, and so the correct thing is happening, possibly by accident (?).

On the basis of these experiments it's not clear to me if there is still a bug here, and if so what it is.

Thanks for following up

> In *web* text fields, none of these bindings work properly, of course - but that's the same in Safari.

Yes, I'm referring to the web text fields. I just tried it in both Safari and Firefox, and none of these bindings work, and that was one of the reasons I use Chrome. 

It makes me feel like arguing something won't be, even though should be, fixed because others do the same. Plus, it worked in Chrome 69. It's frustrating to know if it won't be fixed because of this. 

My experiments: in Safari and Firefox, ctrl-a doesn't work because it has default system binding (go to front). If I set it to be, e.g. ctrl-cmd-a, it works in Safari and Firefox. 

> Right now, I think that the custom hotkey is getting dispatched via BridgedContentView, not Textfield, and so the correct thing is happening, possibly by accident (?).

Are you referring to web text fields, or omnibox? And the correct thing = using the system shortcut?

> On the basis of these experiments it's not clear to me if there is still a bug here, and if so what it is.

IMO yes, because ctrl-a doesn't use system shortcut. What's weird for me is that it works in 69, but not 70+, which is a regression. 

Again, I really appreciate your effort to investigate this. Let me know how I can help. Thanks