Open Bug 1427956 Opened 8 years ago Updated 3 years ago

A changed form element causes the state of the previously-filled section to be cleared

Categories

(Toolkit :: Form Autofill, enhancement, P4)

enhancement

Tracking

()

Tracking Status
firefox59 --- affected

People

(Reporter: lchang, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Whiteboard: [cc-autofill-reserve] [form autofill:V2])

+++ This bug was initially created as a clone of Bug #1423591 +++ Please see bug 1423591 comment 3: > The cause is because the form modification force the later focus drop all > the states of filled section. We should figure out better section > re-construction strategy instead of directly replacing with newly identified > field details. For more details: There is an issue that the autofill'ed status will be reset if the elements inside a <form> element are changed (either added or removed) after one of the sections in this form is filled. That causes some weird situations when re-triggering the dropdown in any input in a previously-filled section. e.g. 1) Clear button doesn't show up in the dropdown. 2) The highlight background color disappears after hovering any item in the dropdown.
Flags: needinfo?(selee)
If we can store the filling status (see the following example) which is hashed by id/name/label strings for each valid field before updating a form, the state could be restored based on these information. If the new fields can match to the signature strings, this means it could be confident to restore the previous state for the field. This can fix the case that some elements are removed or added or even modified. However, I have a concern about the performance of retrieving the label strings. BTW, the restoring logic for <select> element could be more difficult than <input> ones. e.g. [ { fieldName: "address-line1", signatureStrings: ["line1-id", "line1-name", "line1-label"], state: "filled", filledValue: "No. 123, Some St." }, { fieldName: "first-name", signatureStrings: ["first-name-id", "first-name-name", "name-label1", "name-label2"], state: "filled", filledValue: "Darth", }, { fieldName: "last-name", signatureStrings: ["last-name-id", "last-name-name", "last-name-label"], state: "filled", filledValue: "Vader", }, ] I also tried to test Chrome's behavior. If I use Chrome to browse this site [1] and apply [2] or [3] in devtools console for adding and removing element based on `input` event, it can handle the field adding case but removing. After adding an element, the feature in Chrome works even the clear form button. After removing an element, the dropdown in Chrome can not be shown. I guess Chrome binds the state information with input fields instead of another data structure (this is what we did.) [1] https://luke-chang.github.io/autofill-demo/basic.html [2] Element removing: document.querySelector("input[autocomplete=street-address]").addEventListener('input', evt => evt.target.remove()); [3] Element adding: document.querySelector("input[autocomplete=street-address]").addEventListener('input', evt => evt.target.form.appendChild(document.createElement("input")));
Flags: needinfo?(selee)
I should correct the example structure which is an object instead of array, and the item's key should be a hashed string by id/name or something. In addition, the previous state in all input/select elements should be clear after storing them. For the performance concern about retrieving labels, a solution is to not include labels in the hash key, since the label won't change a lot.
Depends on: 1429703
Priority: -- → P3
Priority: P3 → P4
Whiteboard: [form autofill:V2] → [cc-autofill-reserve] [form autofill:V2]
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.