UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36

Steps to reproduce the problem:
1. Create a Chrome Extension that uses a 3rd-party OAuth Authorization Server
2. Initiate an OAuth flow with chrome.identity.launchWebAuthFlow

What is the expected behavior?
The new window should:
1. Use the same cookie container as the rest of the browser
2. Show the address bar to allow the user to see the location

What went wrong?
Cookies are not shared between this window and the rest of the browser.

This is a problem for two reasons:
1. Poor UX:  If the user is already logged in to the authorization server, they need to login again.
2. Horrible security:  The lack of an address bar, combined with the fact that the user will always have to re-enter credentials means that the user has no way to guard against phishing attacks.  Tabs should ALWAYS have an address bar, especially in flows which are explicitly used for auth and therefore most likely require entering credentials.

Did this work before? No 

Does this work in other browsers? N/A

Chrome version: 70.0.3538.102  Channel: stable
OS Version: 10.0
Flash Version: 

From  issue #365200 , which was marked as "Needs-Feedback" and then archived.  This issue needs attention and is not getting any for 4 years.

> I'm using the Dropbox API in an extension, and it adapts by using chrome.identity.launchWebAuthFlow to authenticate. Despite the fact that I've signed into Dropbox through the non-spoofable browser UI, chrome.identity.launchWebAuthFlow launches a new window that's nearly indistinguishable from any App window, and asks for my credentials there. (The distinguishing factor on Mac is that it shows "Identity API Scope Approval UI" in the menu bar, but I had to know to look to see that.)

> It would be better to re-use existing credentials or open the window in a popup that overlaps the browser UI to prevent spoofing.