New issue
Advanced search Search tips

Issue 630032 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Jul 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug



Sign in to add a comment

fedex.com login not recognized by password saver

Project Member Reported by groby@chromium.org, Jul 20 2016

Issue description

Version:  54.0.2800.0
OS: OSX

What steps will reproduce the problem?
(1) Have a saved password and username for fedex.com
(2) Go to www.fedex.com/us
(3) Try to login, and despair

What is the expected output?
Chrome should suggest user name and/or password for the site

What do you see instead?
For the user ID, Chrome instead suggests e-mails from autofill
For the password, no suggestions are available, and no password indicator in the omnibox

Please use labels and text to provide additional information.

 

Comment 1 by vabr@chromium.org, Jul 22 2016

Cc: hwi@chromium.org dvadym@chromium.org
Labels: Hotlist-Polish OS-All
Status: WontFix (was: Untriaged)
(+hwi and +dvadym for mentions in the text below)

Thanks for the report!

The trouble seems to be that while the registration page is on https, the login page is on http. Chrome won't allow filling on purpose, for security reasons.

We thought about this problem and it is not easy. For the special case of pages migrating from HTTP to HTTPS we have a plan of a one-time migration ( bug 571580 ), but that's not the case here.

It is actually a headache for introducing password generation as well (thus Cc-ing dvadym@ in case he has some plan for that I forgot), because if we generated password on https://fedex... and then did not fill it on the http login page, the user might see no way out.

The only workaround here so far is inspect about:settings/passwords and if you trust the http page, copy it over the first time. After that, Chrome should start filling on http.

hwi@ has been working on some interesting UI for filling in reduced security scenarios -- Hwi, has there been some suggestion to make the HTTPS->HTTP case easier for the users, or are the security concerns preventing that?

Sign in to add a comment