1630942 - session restore is restoring old form field data from different pages on the same site when pushState is used to navigate

Status: NEW

(Core :: DOM: Core & HTML, defect, P3)

Description

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:75.0) Gecko/20100101 Firefox/75.0

Steps to reproduce:

In an existing website that uses Turbolinks, I recently (v75) started to notice form fields begin to be filled in with values from similar form fields on different, prior visited urls.

A simple example is https://horse-eastern-coral.glitch.me/index.html if you do the following:

1. view index.html and select a value from the dropdown (like "Mustard")
2. refresh the page; prior value is filled in
3. navigate to one.html
4. refresh the page; prior value from index is filled in
5. (optional) navigate to two.html which pre-selects Barbecue from the html
6. refresh the page; prior value from index is filled in

More info can be found at https://github.com/turbolinks/turbolinks/issues/536 where it was assumed there may be an issue with Firefox's cache performing differently when history state is pushed/replaced.

I did not notice an issue until recently and I'm on Mac Catalina 10.15.4

Actual results:

A selected dropdown value from an old page is pre-filled as the <select>'d option even if I am on a different url.

Expected results:

I would not expect any of the situations to pre-fill an existing form field value after I refresh the page. It would probably be fine for the value to be pre-selected on the same url (step 2), but I would not at all expect that value to show up on other pages (step 4 and 6).

Comment 1

[Firefox Bug Husbandry Bot]

Resetting severity to default of --.

Comment 2

[Negritas Sergiu, Desktop QA]

Hello! I have managed to reproduce this issue following the STR provided in the the description on all OS's and using Firefox 77.0a1(2020-04-21), Firefox 75.0 and Firefox 76.0b6. I will mark the flags accordingly and set a component for this issue so one of our developers could look more into it. If it's not the right component please feel free to change it to an appropriate one.

Comment 3

[Matthew N. [:MattN]]

I don't know if this code falls under session restore of the DOM side so starting here for now.

(In reply to jon from comment #0)

I would not expect any of the situations to pre-fill an existing form field value after I refresh the page.

It would probably be fine for the value to be pre-selected on the same url (step 2),

Yes, that is intentional and the proper way to prevent that is to use autocomplete=off but keep in mind that there are cases a user may need to reload where having the field data preserved would be useful.

but I would not at all expect that value to show up on other pages (step 4 and 6).

Yeah, that seems surprising.

It would be good to know if this is a regression by running mozregression.

Comment 4

[jon]

Attachment: mozregression log

Good call on the bisect as it may have been doing this longer than I would have guessed. I ran mozregression and found it working on nightly 2019-07-01 build. Here's the info:

> pushlog_url: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=add98afa5f0ca1ca17aa87eaa045442a3e1fa07a&tochange=2fd61eb5c69ce9ac806048a35c7a7a88bf4b9652
> repo_name: mozilla-central

-----

```

Comment 5

[jon]

Attachment: screenshot of mozregression results

Comment 6

[Matthew N. [:MattN]]

Thank you very much. The screenshot points to bug 1553705.

Comment 7

[Matthew N. [:MattN]]

Perhaps this is actually a dupe of bug 1618269… I didn't dig deep enough to see.

Comment 8

[Hsin-Yi Tsai (she/her) | away [:hsinyi]]

Hey Cameron, can you take a look?

Comment 9

[Firefox Bug Husbandry Bot]

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is -- (non,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)

Comment 10

[Cameron McCormack (:heycam)]

Sorry I didn't get a chance to look at this.