Sounds similar to  Issue 692377  ...

MacViews triage: I can repro this locally. Over to robliao@ - let's target M-68.

Pls mark the bug as fixed if CL is landed in trunk and nothing else is pending. Thank you.

I just saw this issue on 68.0.3409.0 (+views-browser-windows). I can reproduce it, but not in a fresh user-data-dir - for some reason then it takes me to
https://accounts.google.com/signin/chrome/sync/identifier?ssp=1&continue=https%3A%2F%2Fwww.google.com%2F&flowName=GlifDesktopChromeSync
instead of giving me the usual modal popdown.

I noticed this because I tried to cmd-A my password and retype it (after making a typo). Cmd-A did nothing.

I cannot repro this on 69.0.3445.0.

I created a clean user-data-dir, logged in, and then logged out
Then I went to chrome://welcome, clicked "Sign In"
and then copy+pasted an e-mail. The email pasted into the e-mail field.

If this repros with a different set of setups, reopen and adjust the description to specify the new steps. Thanks!

I'll also add my redirect was
https://accounts.google.com/signin/chrome/sync/identifier?ssp=1&continue=https%3A%2F%2Fwww.google.com%2F&flowName=GlifDesktopChromeSync

And it appears to work fine.

Do we have any idea what causes it to redirect vs using the modal popdown? IIRC the bug only manifested in the modal.

Is it somehow caused by stale userdata from previous chrome versions?

It may be triggered on variations. Do you have any other active chrome://flags and/or experiments?

Somehow my current user-data-dir (the fresh one from #10) is using the modal again, even though it used to not. And the problem still manifests (cmd-A doesn't work) (-> reopening).

c134752e-6d5b49a5
411b6d4e-3f4a17df
fe69e053-94941f92
d01ab0d3-f23d1dea
59aeb88e-3f4a17df
34a6bf44-ca7d8d80
a6674cf-ca7d8d80
da89714-4ad60575
9041608a-f23d1dea
1e528f0f-f23d1dea
afb5d7b8-a2bfa3a0
9853922b-c200976c
6025934e-3f4a17df
7c1bc906-b5809d46
47e5d3db-3d47f4f4
125b7f68-65bced95
d442dfb7-df59a0c
6557d030-6557d030
a582a1b8-ad75ce17
3042ad4b-59e92cae
267255c3-f4950e99
ac6e1b9-d93a0620
44827ee5-43146c13
9eab0f00-3f4a17df
d0ecf1da-12de74c0
345b5b61-3f4a17df
5485fc4d-3f4a17df
937cad47-65bced95
9773d3bd-ca7d8d80
93731dca-e89d496c
41f007f9-f23d1dea
c992f345-4ad60575
9e5c75f1-e406a769
350fabdd-34b13816
f79cb77b-3f4a17df
fb4ab4bb-3f4a17df
4ea303a6-249c509
874c031e-f23d1dea
bcc34a89-3f4a17df
6e6e0c7e-bfd1fe3
d92562a9-65bced95
2b33233e-cc2bd7de
2c1d398c-f23d1dea
6973a1cf-3f4a17df
ad6d27cc-c6d02f41
f242806f-5810b593
da460ac8-65bced95
23496387-4ea78229
5a42b5d9-10ffa667
344833e9-473e8c2e
3f273a97-e3ad1896
4bc337ce-69465896
57789a80-2d8bc89
9a2f4e5b-f46d6bfd
494d8760-52325d43
3ac60855-3ec2a267
f296190c-72d8285f
4442aae2-d7f6b13c
ed1d377-e1cc0f14
12e17bc5-e1cc0f14
75f0f0a0-e1cc0f14
e2b18481-e1cc0f14
e7e71889-e1cc0f14
3a4029d-3a4029d
bbb8f811-3f4a17df
6a51bb09-f23d1dea
6b5f0f2d-f23d1dea
cc73f8a1-a3a14831
8834fcca-cf4f6ead
c42e52b-2599138c
81c6897f-3d47f4f4

Actually, I tried creating new user data dirs 6 times on 69.0.3445.2, and I got the modal every time. Maybe the modal was being finch trialed, and has now gone to 100%? Just creating a new user-data-dir and enabling views-browser-windows is sufficient to reproduce now.

/Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary --user-data-dir=/tmp/t --enable-features=ViewsBrowserWindows

https://screencast.googleplex.com/cast/NTM5Mjc0MDMwOTI3MDUyOHxkYzhlNDNkMy1lZg
Here's a screencast. During the time I'm in the "email" box, I try pressing cmd-A a few times and it doesn't do anything. However the "Edit>Select All" option works fine.

macOS 10.13.4 (17E202)

Does pasting from the menu work?

Yes, pasting from the Edit menu into the modal dialog works.

I tried to see if I could paste from the right click menu... but I just discovered a (possibly unrelated) bug with the modal: I can't right click in it. Right clicks select the hovered word (like normal), but no right click menu comes up.

This sounds like a hotkey issue then. Routing to erikchen@.

I'm trying to figure out exactly what causes it to use the modal or non-modal signin flow. For now, I think I'm able to consistently get the modal one, and repro, by using --force-variations-ids --enable-features=ViewsBrowserWindows

sorry, that's --force-variation-ids , I made a typo.

update: even --force-variation-ids doesn't seem to be changing the behavior anymore. On top of that, I've apparently updated to an unstable version of canary. I'll update again if I figure anything out.

Downloaded 563740 from
https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Mac/563740/
and I think this seems to be reliably reproducing:
--user-data-dir=/tmp/t1 --disable-field-trial-config --enable-features=ViewsBrowserWindows

I think the modal vs nonmodal is somehow controlled by the AccountConsistency trial, but I haven't been able to prove that.

FYI, even cmd-q doesn't work while in the signin modal.

I can confirm this works for me on Chromium builds. I'll update the description.

Note to self: Modifying -[RenderWidgetHostViewCocoa performKeyEquivalent:] to return NO fixes this issue.

This problem applies to all views platforms. Command commands like ctr+W, ctr+T, etc. do not work on Linux with the dialog present. copy paste does work though [likely because that goes through a different code path].

Root problem: The shortcut is sent to the renderer. The renderer chooses not to handle it, which calls back into RenderWidgetHostImpl::OnKeyboardEventAck. This calls SigninViewControllerDelegate::HandleKeyboardEvent, which proceeds to drop the event on the floor.

The reason this works in Cocoa is that SigninViewControllerDelegateMac::HandleKeyboardEvent calls "[[NSApp mainMenu] performKeyEquivalent:event.os_event];". this is not the right way to handle hotkeys, as it misses global hotkeys, but it at least works for important commands like cmd + c.

To handle this properly, SigninViewControllerDelegate should behave like BrowserView::HandleKeyboardEvent. On macOS, it should redispatch the event like BrowserFrameMac::HandleKeyboardEvent. On other views platforms, it should call views::UnhandledKeyboardEventHandler::HandleKeyboardEvent().

> On macOS, it should redispatch the event like BrowserFrameMac::HandleKeyboardEvent. On other views platforms, it should call views::UnhandledKeyboardEventHandler::HandleKeyboardEvent().

Can we make mac use UnhandledKeyboardEventHandler as well?  It should already be funnelling through ui/command_dispatcher.mm and its delegates, which should be able to bubble up to a Browserview's command dispatcher.

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

commit 6fbe39834bb4117ae239551740f4dbc19477a361
Author: erikchen <erikchen@chromium.org>
Date: Mon Jun 18 17:32:35 2018

Make accelerators work on Signin modal dialog.

Previously, only some accelerators worked in Windows/Linux [e.g. ctr + V works,
ctr + T did not]. All accelerators were busted on macOS Views. Some accelerators
were busted on macOS Cocoa.

The root cause is that SigninViewControllerDelegateViews::HandleKeyboardEvent
was not implemented on Views, and
SigninViewControllerDelegateMac::HandleKeyboardEvent was incorrectly implemented
on macOS.

This CL fixes both implementations to use the now standard logic for
redispatching key events. This CL also fixes the implementation of
CommandDispatcher on macOS to correctly detect whether an event is being
redispatched.

Change-Id: I76b1ef263fce171ae182d316f541f836ab6388ee
Bug:  776304 
Reviewed-on: https://chromium-review.googlesource.com/1097206
Commit-Queue: Erik Chen <erikchen@chromium.org>
Reviewed-by: Trent Apted <tapted@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568052}
[modify] https://crrev.com/6fbe39834bb4117ae239551740f4dbc19477a361/chrome/browser/ui/cocoa/apps/native_app_window_cocoa.mm
[modify] https://crrev.com/6fbe39834bb4117ae239551740f4dbc19477a361/chrome/browser/ui/cocoa/browser_window_cocoa.mm
[modify] https://crrev.com/6fbe39834bb4117ae239551740f4dbc19477a361/chrome/browser/ui/cocoa/browser_window_utils.mm
[modify] https://crrev.com/6fbe39834bb4117ae239551740f4dbc19477a361/chrome/browser/ui/cocoa/chrome_event_processing_window.mm
[modify] https://crrev.com/6fbe39834bb4117ae239551740f4dbc19477a361/chrome/browser/ui/cocoa/extensions/extension_view_mac.mm
[modify] https://crrev.com/6fbe39834bb4117ae239551740f4dbc19477a361/chrome/browser/ui/cocoa/profiles/signin_view_controller_delegate_mac.mm
[modify] https://crrev.com/6fbe39834bb4117ae239551740f4dbc19477a361/chrome/browser/ui/signin_view_controller_delegate.cc
[modify] https://crrev.com/6fbe39834bb4117ae239551740f4dbc19477a361/chrome/browser/ui/signin_view_controller_delegate.h
[add] https://crrev.com/6fbe39834bb4117ae239551740f4dbc19477a361/chrome/browser/ui/signin_view_controller_interactive_uitest.cc
[modify] https://crrev.com/6fbe39834bb4117ae239551740f4dbc19477a361/chrome/browser/ui/views/frame/browser_frame_mac.mm
[modify] https://crrev.com/6fbe39834bb4117ae239551740f4dbc19477a361/chrome/browser/ui/views/profiles/signin_view_controller_delegate_views.cc
[modify] https://crrev.com/6fbe39834bb4117ae239551740f4dbc19477a361/chrome/browser/ui/views/profiles/signin_view_controller_delegate_views.h
[modify] https://crrev.com/6fbe39834bb4117ae239551740f4dbc19477a361/chrome/test/BUILD.gn
[modify] https://crrev.com/6fbe39834bb4117ae239551740f4dbc19477a361/ui/base/cocoa/command_dispatcher.h
[modify] https://crrev.com/6fbe39834bb4117ae239551740f4dbc19477a361/ui/base/cocoa/command_dispatcher.mm
[modify] https://crrev.com/6fbe39834bb4117ae239551740f4dbc19477a361/ui/views/cocoa/native_widget_mac_nswindow.mm
[modify] https://crrev.com/6fbe39834bb4117ae239551740f4dbc19477a361/ui/views/controls/webview/unhandled_keyboard_event_handler_mac.mm

Thanks Erik for the fix!