As clarification:
*the issue has only been seen to occur when attempting to access the LoginPrompt (selecting "sign in to chrome" from the avatar menu)
*the client is connected behind an authenticating web proxy
*the client OS has proxy configuration provided through a PAC file (chrome is configured to detect proxy settings from the OS)
*SSL interception is being performed

The crash does not seem to occur when using Fiddler to automatically inject proxy credentials, or when connecting to the Internet through a non-proxied connection (e.g. a mobile hotspot).

Could you please try logging from incognito window?

Also share the crash id from chrome://crashes for further investigation.

Thanks for the report. Request you to please provide us with sample website link, with which will help us triage the issue further.


Thank you!

Looks like WebContentsModalDialogManager::FromWebContents is returning NULL.  Presumably either the WebContents has been destroyed, or just doesn't have a WebContentsModalDialogManager for some reason.

CCing owners of components/web_modal/ and chrome/browser/ui/login.

It's likely whatever WebContents is generating the dialog does not have a WebContentsModalDialogManager created for it via web_modal::WebContentsModalDialogManager::CreateForWebContents(). The manager is necessary to show web modal dialogs generated by the WebContents.

+hcarmona, who looked into similar issues with other dialogs.

Sounds pretty similar to bug 543453, possibly a dupe. Unfortunately we weren't able to repro there.

Just a minor update that Bryan is testing it with incognito and gathering some crash ids.

The "What steps will reproduce the problem?" section needs a little more detail...  If someone can edit the "steps to reproduce" section of this issue report with the following, it'll go a long way towards helping everyone understand what we're running into:

---
[1] Launch Chrome in normal mode
[2] Activate the avatar menu by clicking on the little silhouette
[3] Click on the "Sign in to Chrome" button

At this point, the LoginPrompt window is drawn, then the Chrome window immediately closes.  There is no "aw snap" message from Chrome, nor is there any dialog raised by the OS about an application unexpectedly quitting.

It's important to note that our LAN is behind an authenticating web proxy.  When I use these same computers to access the LoginPrompt while connected to a network with no authenticating proxy, or when using Fiddler to automatically include proxy credentials in the http/https headers, the LoginPrompt works fine - no crash.

A quick packet capture seems to show that the crash occurs shortly after an https connection attempt to ssl.gstatic.com.  Our proxy responds with the typical http 407 error (proxy authentication required), to which the client responds with a series of RST, ACK packets as the application crashes.
---

Testing this in incognito mode doesn't apply, since incognito mode lacks the avatar menu and the crash only occurs when clicking on the "Sign in to Chrome" button.

The chrome://crashes shows "You have no recently reported crashes..." even after enabling the "Automatically send usage statistics and crash reports to Google".  Dump files are being created in the "...\User Data\Crashpad\reports" folder, but nothing in chrome://crashes.

If there's something else that I need to do to enable crash reporting, please let me know.

Adding sign-in-related components, because the reproduction is relevant to that.

Request MTV team to look into the issue.

There's some confusion here because the LoginPrompt you're seeing in the stack is the proxy authentication prompt, not the sign in to Chrome prompt (as referred to in #1).

The crash seems to happen when Chrome tries to show a modal dialog (the proxy auth prompt) on top of the tab-modal Sign In Flow. As a modal dialog itself, the sign in flow's WebContents doesn't have a WebContentsModalDialogManager because we don't show dialogs on top of dialogs.

In any case, this is the same bug as  Issue 633287  so I'll merge it in that one. You should be able to work around it by disabling chrome://flags/#enable-password-separated-signin-flow in the meantime.

Oops, meant "this is the same bug as Issue 629529" in the previous comment.

From Bryan's testing: "FYI, disabling the flag that they recommend (Enable new gaia password-separated sign in flow) does prevent the crash from occurring.  Unfortunately, it also prevents the sign-in from working at all.  The sign-in window allows the user to enter a username and password, but displays an “uh-oh!” message and squawks that something went wrong."

We have a partial workaround by having the user log into the proxy before logging into the browser, but that has also been inconsistent.