New issue
Advanced search Search tips

Issue 855987 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner: ----
Closed: Aug 31
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac
Pri: 2
Type: Bug

Blocking:
issue 861759



Sign in to add a comment

Password form server predictions off for itemku.com

Project Member Reported by vabr@chromium.org, Jun 25 2018

Issue description

Chrome Version       : 69.0.3473.0
OS Version: 
URLs (if applicable) : https://itemku.com/daftar?returnurl=%2F

The linked site contains a registration form. Its password field is marked autocomplete="new-password". Without server hints, Chrome parses the form correctly, because it identifies the new password field, and, by luck, the preceding text input (e-mail) is what the page uses as a username.

However, the predictions for the form look like this:

Server predictions: {
Signature of form: 17285649522930244763
Origin: https://itemku.com/
Action: https://itemku.com/
Form fields: 
name: 3489289364, type=text, SERVER_PREDICTION: NAME_FULL
email: 1029417091, type=email, SERVER_PREDICTION: EMAIL_ADDRESS
password_no_confirm: 134088744, type=password, autocomplete=new-password
phone: 1794903826, type=tel, SERVER_PREDICTION: PHONE_HOME_CITY_AND_NUMBER
}

There are two issues:
(1) 'email' should be USERNAME_AND_EMAIL_ADDRESS
(2) password_no_confirm should be ACCOUNT_CREATION_PASSWORD

The new parser (run Chrome with --enable-features=new-password-form-parsing) only checks the server hints and hence recognises no username and misunderstands the new password as current password.

The latter is not clear to vabr@ yet (why does the new parser use the server prediction when there is no password hinted at?), this will be clarified ASAP.

 

Comment 1 by vabr@chromium.org, Jun 25 2018

Labels: -Pri-1 Pri-2
Filling works on that site (login form is easy), so downgrading the priority.

Comment 2 by vabr@chromium.org, Jun 26 2018

Cc: vabr@chromium.org
Owner: ----
Status: Available (was: Started)
To explain why the parser uses server predictions while the logs seem to indicate there are none:
(1) There indeed is a server prediction that |password_no_confirm| is a PASSWORD (type 75), it's in AutofillField::server_type().
(2) The logs use AutofillField::Type(), which are computed based on mutliple sources of information (and in this case the server hint gets overridden).

Perhaps the logs should use the same what the parser uses.

But this issue is caused by unhelpful server data, not a bug in the parser.
Project Member

Comment 3 by bugdroid1@chromium.org, Jun 27 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/bb3da314544e64b99dbbfd68042649be3dbd13a1

commit bb3da314544e64b99dbbfd68042649be3dbd13a1
Author: Vaclav Brozek <vabr@chromium.org>
Date: Wed Jun 27 15:36:28 2018

Output AutofillField::server_type() in password internals

Currently, chrome://password-manager-internals shows
AutofillField::Type() as server predictions. This is not completely
accurate, because Type() comes from multiple sources, and actually, it
is AutofillField::server_type() which is passed to the password form
parser as server predictions.

Therefore this CL changes the internals page to output server_type()
instead.

Bug:  855987 
Change-Id: Ib4bf8cdcbca21ee38450d6d0a0026dd2da71b2e5
Reviewed-on: https://chromium-review.googlesource.com/1114850
Reviewed-by: Vadym Doroshenko <dvadym@chromium.org>
Commit-Queue: Vaclav Brozek <vabr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#570784}
[modify] https://crrev.com/bb3da314544e64b99dbbfd68042649be3dbd13a1/components/password_manager/core/browser/browser_save_password_progress_logger.cc

Blocking: -845426
Blocking: 861759
Status: Fixed (was: Available)
Server predictions have been fixed for itemku.
Cc: -vabr@chromium.org

Sign in to add a comment