1751215 - Form values accessed in script are not the same as shown on screen after page reload

Status: NEW

(Firefox :: Session Restore, defect, P2)

Description

[Jeremy]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:96.0) Gecko/20100101 Firefox/96.0

Steps to reproduce:

1. Make a change to a form select and checkbox on a web form
2. Get values of above form fields in script
3. Close browser window
4. Re-open browser window
5. Form field value changes made in step 1 persist (on screen)
6. Repeat step 2

Actual results:

The form field values retrieved in step 6 above, from script, are not the same as those shown on screen, i.e. the changed values, insead they are the default values.

Expected results:

I would expect the form values in script to be the same as those shown on screen. Issue occurs on Android FF browser also.

I have made a demo here to illustrate:
https://jeremywray.co.uk/bug/firefox_bug_test.html

Comment 1

[Alice0775 White]

I can reproduce the issue in Nightly98.0a1 Windows10.
Disabling fission fixes the issue.

Comment 2

[Pascal Chevrel:pascalc]

Andrei Cculd we get a more precise bisection? Thanks

Comment 3

[Peter Magyari (Desktop QA)]

Hi,

As far as I can tell, the issue has been there ever since fission landed, I've enabled it on a build from 2020-01-01 and the issue was reproducible.

Comment 4

[Pascal Chevrel:pascalc]

(In reply to Peter_M from comment #3)

Hi,

As far as I can tell, the issue has been there ever since fission landed, I've enabled it on a build from 2020-01-01 and the issue was reproducible.

We want to know what patch introduced the regression before fission was activated, can you please use mozregression with the fission pref set to find it out please? Thanks

Comment 5

[Peter Magyari (Desktop QA)]

This is the pushlog I've got from running mozregression: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=7db5c3e9f7ba76ca8396199f5f90334a39ccbeda&tochange=72798e840772beb4c8f760ca94271f0cdb877a69

I believe Bug 1572084 might be the culprit.

Comment 6

[Chris Peterson [:cpeterson]]

farre, this bug looks like a regression from your fix for SessionStoreListener bug 1572084.

Comment 7

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

Andreas is finishing his big patches around session store in https://bugzilla.mozilla.org/show_bug.cgi?id=1739450
Let's see if this issue will be resolved along.

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1572084

Comment 9

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

Hi, do you still see this issue on the latest nightly? I seemed to not see this with https://jeremywray.co.uk/bug/firefox_bug_test.html
After I restarted a window, the values on the checkbox or read from script were all set back to default. So they were consistent. Thank you.

Comment 10

[Alice0775 White]

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #9)

Hi, do you still see this issue on the latest nightly? I seemed to not see this with https://jeremywray.co.uk/bug/firefox_bug_test.html
After I restarted a window, the values on the checkbox or read from script were all set back to default. So they were consistent. Thank you.

I can still reproduce this on Nightly102.0a1(20220503094208) Windpes10.

Comment 11

[Andreas Farre [:farre]]

This happens, I think, because we get the load event before we restore the page. If you look at the value in the debugger, you'll see that document.querySelector("select").value indeed contains the correct value after closing a tab, and undoing the close. Even though the value as read when the load event fires hasn't been restored.

This makes me suspect that it has more to do with restoring than collecting, and could then be a bug due to any of the bugs listed in bug 1751215.

On the other hand, I'm not sure that we've ever restored session store data before load is complete. That would make it impossible to know that all the form elements to restored were loaded to begin with. Maybe we've changed behavior to restore after the load event fires, and that that was different than before Fission. But I'm not sure of that. Adding :dao, who maybe knows.

It's fully possible that this might be intended behavior.