save password prompt not shown if about:blank was loaded in the tab |
||||
Issue descriptionChrome Version: 64.0.3242.0 What steps will reproduce the problem? (1) Open Chrome with about:blank page (set as startup URL or such) ; enough to open about:blank in a tab (2) Open https://httpbin.org/basic-auth/user/passwd (3) Enter credentials: user/passwd when prompted What is the expected result? Save password dialog to be shown after the page loads What happens instead? No prompt to save password. If the tab loaded another page before the http auth is triggered, then password prompt is shown correctly. Seems like if the previous page is about:blank this issue happens.
,
Oct 18 2017
I think the about:blank behavior changed when I disallowed passwords on about:blank pages as part of issue 756587, and I've confirmed that reverting r503339 locally fixes this. *However*, I don't understand why the prompt to save passwords is gated on the old page's URL (about:blank) rather than the one being navigated to, which actually needs the credentials stored. That seems like a bug. Looking a bit closer, the problem is in the browser-side check in ChromePasswordManagerClient::IsPasswordManagementEnabledForCurrentPage(), which sets |is_enabled| to false for about:blank (added in r503339) and a couple of other cases. That's reached when trying to save HTTP auth credentials first via LoginView::LoginView() -> PasswordManager::AddObserverAndDeliverCredentials() -> PasswordManager::CreatePendingLoginManagers(), and then when submitting the credentials via LoginHandler::SetAuth() -> PasswordManager::ProvisionallySavePassword(). Seems like IsPasswordManagementEnabledForCurrentPage() is always using GetLastCommittedEntry(), whereas in this case it might need to look at the pending entry instead? This also means this bug isn't specific to about:blank -- the other conditions that set |is_enabled| to false are a problem too. E.g., the same bug repros if I start Chrome at chrome://chrome-signin/foo and then navigate to https://httpbin.org/basic-auth/user/passwd. vabr@: can you please triage this from the password side?
,
Oct 19 2017
Thanks for the helpful analysis! CL started: https://chromium-review.googlesource.com/c/chromium/src/+/727764
,
Oct 19 2017
Status update: I need to rework the above code change to also apply to IsSavingAndFillingEnabledForCurrentPage.
,
Oct 20 2017
Status update: behind on my schedule. This is my #2 coding task, #1 being bug 769381 . I expect to get to this next week.
,
Oct 24 2017
Status update: https://chromium-review.googlesource.com/c/chromium/src/+/727764 got an overhaul today. Letting the trybots run overnight and will hopefully be able to send out for review tomorrow.
,
Oct 25 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a8bdf0becf0459d641b2901c3763d9f68668e0bb commit a8bdf0becf0459d641b2901c3763d9f68668e0bb Author: Vaclav Brozek <vabr@chromium.org> Date: Wed Oct 25 14:56:08 2017 [Passwords] Use visible navigation entry for HTTP auth Password manager determines for each site, whether it should be enabled or not. An example site where it is not enabled is, e.g., about:blank. On normal web pages it should be enabled except when the user disabled it, there are SSL errors, etc. Password manager does this check when it sees new password forms. HTML password forms only appear after the navigation to the page containing them is already committed. Therefore the navigation entry to check is NavigationController::GetLastCommittedEntry. HTTP auth forms (basic and digest), on the other hand, appear during the navigation and before it is committed. The check needs to relate to the URL in the Omnibox, hence NavigationController::GetVisibleEntry should be used. This CL teaches PasswordManager to keep track of what entry to look at and ChromePasswordManagerClient to use that guidance for checking the actual navigation entry. The iOS implementation of PasswordManagerClient does not need to do this so far, because HTTP auth is not supported on iOS yet (https://crbug.com/540699). Bug: 775842 ,540699 Cq-Include-Trybots: master.tryserver.chromium.mac:ios-simulator-cronet Change-Id: I08b6a9770b0ec710b02a271d00b692967934271a Reviewed-on: https://chromium-review.googlesource.com/727764 Reviewed-by: Vasilii Sukhanov <vasilii@chromium.org> Commit-Queue: Vaclav Brozek <vabr@chromium.org> Cr-Commit-Position: refs/heads/master@{#511458} [modify] https://crrev.com/a8bdf0becf0459d641b2901c3763d9f68668e0bb/chrome/browser/password_manager/chrome_password_manager_client.cc [modify] https://crrev.com/a8bdf0becf0459d641b2901c3763d9f68668e0bb/chrome/browser/password_manager/chrome_password_manager_client_unittest.cc [modify] https://crrev.com/a8bdf0becf0459d641b2901c3763d9f68668e0bb/chrome/browser/password_manager/password_manager_browsertest.cc [modify] https://crrev.com/a8bdf0becf0459d641b2901c3763d9f68668e0bb/components/password_manager/core/browser/password_manager.cc [modify] https://crrev.com/a8bdf0becf0459d641b2901c3763d9f68668e0bb/components/password_manager/core/browser/password_manager.h [modify] https://crrev.com/a8bdf0becf0459d641b2901c3763d9f68668e0bb/components/password_manager/core/browser/password_manager_unittest.cc
,
Oct 26 2017
|
||||
►
Sign in to add a comment |
||||
Comment 1 by isherman@chromium.org
, Oct 18 2017Components: UI>Browser>Passwords