Open Bug 1849215 Opened 2 years ago Updated 7 months ago

[US][potterybarn.com, williams-sonoma.com] The State field (dropdown) is not reset to the default value (State) after clearing the form

Categories

(Toolkit :: Form Autofill, task, P3)

Firefox 118
Desktop
All
task

Tracking

()

Tracking Status
firefox118 --- affected

People

(Reporter: ailea, Assigned: theidkamp)

References

(Blocks 1 open bug, )

Details

(Whiteboard: [fxcm-addr-compatibility])

Attachments

(4 files)

Attached video 2023-08-17_21h28_37.mp4

Found in

  • 118.0a1

Affected versions

  • 118.0a1

Tested platforms

  • Affected platforms: Windows 10

Preconditions

  • browser.search.region = US
  • Have at least one Address already saved

Steps to reproduce

  1. Reach the Address form on https://www.williams-sonoma.com or https://www.potterybarn.com
  2. Click on any Address field and select an Address entry from the dropdown
  3. Click on any field and choose the Clear Form option

Expected result

  • The State field should be reset to its default value (State)

Actual result

  • The State field is not cleared upon clear form, the value is not reset to the initial one (State)

Regression range

  • N/A

Aditional Notes

I can't reproduce this issue. The state is cleared back to the default value 'State' after clearing.

Hi Alin, could you help take a look to see if you can still reproduce this issue now? thanks!

Flags: needinfo?(ailea)
Attached video 2024-04-09_11h22_07.mp4

Hi,
Unfortunately, I am still able to reproduce the issue on both websites (both websites seem to use the same shipping address form) using the latest Nightly build 126.0a1 (2024-04-08). See the screen recording attached to this comment.

Flags: needinfo?(ailea)

This site is updating the "selected" attribute on the <option> element whenever it is assigned a new value. The selected attribute is supposed to be used for the default value, not the current value, so when a clear action is performed, we assume that the default value is the value to reset back to, which is different than expected.

One way to handle this is to instead cache the default option value before autofilling, so we can reset back to the original option.

Whiteboard: fxcm-addr-compatibility
Whiteboard: fxcm-addr-compatibility → [fxcm-addr-compatibility]
Priority: -- → P3
Assignee: nobody → theidkamp

Hi Alin, could you help test whether Chrome has the same issue or not? thanks!

Flags: needinfo?(ailea)
Attached video 2024-08-14_13h39_15.mp4

Hi Dimi. Chrome does not have the issue described in this bug, the State dropdown is reset accordingly to the default "State" value (see the video attached to this comment).

Flags: needinfo?(ailea)

(In reply to Alin Ilea, Desktop Test Engineering from comment #7)

Hi Dimi. Chrome does not have the issue described in this bug, the State dropdown is reset accordingly to the default "State" value (see the video attached to this comment).

Thank you for testing!

Chrome's behavior is "undo autofill". That means when they do autofilingl, they record the value before autofilling, and when users click "undo", the value is then restored. However, our implementation is "clear form". We don't record the value before autofilling, when users click "clear", we simply reset <input> to empty and <select> to the default value, which in this case, is correct because this is how the selected attribute works.

I would suggesting discussing with UX regarding what is a better behavior, if we decide to keep the "clear form" behavior, then this bug could be a WON'T FIXED

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: