Form predictions: mismatch of the number of fields |
||
Issue description(0) Revert r567613. (1) Go to https://login.ubuntu.com/ (2) Click the radio button "I don’t have an Ubuntu One account" Inside password_manager::ConvertToFormPredictions, observed_form.fields.size() != form_structure.field_count(). This means that the server hint for the form expects a different number of fields than actually found on the form. This is caused by the page changing the form dynamically (to reuse a login form as a sign-up form). The cited r567613 was handling this by giving up on the server predictions in this case, to avoid crash. https://crbug.com/853149#c6 and https://crbug.com/853149#c7 have some ideas how to be able to reuse the server hints after all. We should fix this properly (instead of giving up to avoid the crash), unless we are sure that in such cases the server predictions are useless after the form change anyway.
,
Jun 24 2018
No, by a proper fix I meant mapping the already stored field hints to the actual fields by something else than the same offset in the list. Address autofill seems to use AutofillField::unique_name_ for that purpose and we could likely convert it to use unique renderer IDs instead (and reuse that for both passwords and address autofill). I did not have time to understand the current code well enough to know how to do this, yet.
,
Jun 26 2018
As we just tested, this should create a new PasswordFormManager that parses the form again, right?
,
Jun 27 2018
I'm not sure what happens, yet. Once somebody has time to look into this, we can trace what (New)PasswordFormManagers are being created and what FormStructures are being passed around. |
||
►
Sign in to add a comment |
||
Comment 1 by battre@chromium.org
, Jun 22 2018