New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 775842 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
hobby only
Closed: Oct 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

save password prompt not shown if about:blank was loaded in the tab

Project Member Reported by ha...@opera.com, Oct 18 2017

Issue description

Chrome 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.

 
Cc: -isherman@chromium.org
Components: UI>Browser>Passwords
Cc: vasi...@chromium.org dvadym@chromium.org engedy@chromium.org battre@chromium.org
Components: UI>Browser>Navigation
Owner: vabr@chromium.org
Status: Assigned (was: Untriaged)
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?

Comment 3 by vabr@chromium.org, Oct 19 2017

Status: Started (was: Assigned)
Thanks for the helpful analysis!

CL started: https://chromium-review.googlesource.com/c/chromium/src/+/727764

Comment 4 by vabr@chromium.org, Oct 19 2017

Status update: I need to rework the above code change to also apply to IsSavingAndFillingEnabledForCurrentPage.

Comment 5 by vabr@chromium.org, 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.

Comment 6 by vabr@chromium.org, 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.
Project Member

Comment 7 by bugdroid1@chromium.org, 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

Comment 8 by vabr@chromium.org, Oct 26 2017

Status: Fixed (was: Started)

Sign in to add a comment