v151.0.4 session-memory change relating to radio button state?

I quickly checked using https://www.w3.org/WAI/ARIA/apg/patterns/radio/examples/radio/ and can't get to store any selected value between restarts. Might be local file://–specific, or something related to the actual JS of your page?

Could you reproduce the same with any form/UI hosted online?

jbr: One can rule out JS as the page doesn't use any. As for the theory that being locally hosted might be a factor, I just copied the page in question to my online storage, opened it, changed the active notebook tab, and closed FF. On restarting, it still clung to the same notebook tab, the same behavior as with the local copy.

My best theory is that it somehow relates to a change in the handling of the checked attribute: whereas before 151.0.4 it was honored after the browser had initially rendered the page using some other item, now it sticks with the one preserved from the prior session. If that's it, the question is whether this is by design or accidental.

You can try to run mozregression to pinpoint the exact change that would visibly change this behavior.

jbr: Alas, my environment here doesn't readily lend itself to using mozregression. I could, however, contribute a simplified test file that demonstrates the problem if it's of any value.

Maybe I should just enter this as a bug; that way I can learn whether it's intentional or inadvertent and, if the latter, maybe even get a fix for it -- though, as mentioned, I could simply live with it this way without much grief.

The fun thing about mozregression is that every single version it pulls is run from a temp dir pointed at a temp location for its profile folder for you that's cleaned up between each bisection run, so whenever you need to run it, your normal browser and profile are safe from those runs — you can just alternatively pick your profile folder for it to clone, to e.g. use your current sessionrestore data for the experiments, or it can also run completely isolated in a blank slate.

But thinking of it now, its ephemeral nature doesn't work out ideally for this use case where you want to see things between restarts (the log output tells which tmp folder .exe it ran so you'd be able to launch the version again manually by re–running the same command, but that might be a little overwhelming for a first time.)

Given the minimal reproducible example wasn't included, I was not able to look whether it's some CSS activation/focusing state that might get cached etc. so I had too little to look for in bugzilla — to first check if that's a feature shipped, or a deliberate choice with prior timeline of decisions. (The pushlog from mozregression would point to the exact patch, and its bugzilla history, to see if the result indeed might be intentional.)

If you're able to provide a reproducible example and willing to file a bug, that's definitely a way to learn if the current behavior is expected or not. Thanks!

I could go ahead and enter this as a bug, but meanwhile I discovered the minimal reproducible example (for me, anyhow) is pretty minimal indeed; the code within the body tag is simply:

       <fieldset><legend>Fieldset</legend>
           <label><input type="radio" name="a" checked>First</label>
           <label><input type="radio" name="a">Second</label>
       </fieldset>

So this boils down to an issue of inter-session radio-button persistence. In v152.0 the state from a prior session has become more persistent.

Now I'm intrigued! (I was about to say it doesn't seem to reproduce for me as I just had jsfiddle.net/3du845jb for the reproduction, but it does not exhibit when the page is more complex, like in this case several document DOM trees and frames intertwined… however when I only pop out the resulting output as a single document, I can see it now clearly — the initial load loads the default state, and later at some point the previous form value gets restored.)

I'll try to see if I could track down any meaningful change pertaining to this.

There seems to be form values being remembered in sessionrestrore, e.g. with jsfiddle.net/jqL93e0g I also get any text input entered restored — so for simple forms that can be restored with IDs or their element path according to https://firefox-source-docs.mozilla.org/toolkit/components/sessionstore/collection.html#structure-of-the-collected-data this should be fairly common. Will look for any recent changes around this if there's anything relevant, and will report back.

(Or it can be just a timing change. Now the restore of form data might be postponed so that it only triggers after all the loading's done, as to not get overwritten by the load default again?)

I can see arguments both for and against this new behavior. Maybe ideally it should be configurable?

So I ran mozregression years back all the way to v128.0 and this behavior was consistent for me in all the versions — both the restore point, and the saved content. (I did not first test whether these versions were perhaps not storing the form value TO sessionstore, but just restoring FROM the current profile sessionstore as saved before the test runs; but later ran a profile randomly saving form/radio/input states between the bisections as well and got them restored all the time to their previous value, saved and then restored across a wide span of versions.)

So this particular minimal reproducible example always saved the radio value.

I'd say the feature is beneficial to its use cases, so I'd look into how to resolve the workflow for your particular homepage, but still keep the possibility of when, if, one day you actually need the restore functionality, and you might appreciate it actually saving your form inputs, you won't lose your content. — If it's about the tab selected on your page, I'd look into domready events, see if they are fired normally on restore, and hook an event/timer to that to re–set your radio value with some delay to the one you'd like to see after every page load — to override any restored form values for the initial layout you need to see.

"So this particular minimal reproducible example always saved the radio value."

The radio-button state was indeed being saved and even restored all along as far as I recall, but up until 152.0 it was then being reset to the button with the checked attribute a few seconds into FF's initializing sequence. I confess this behavior had minimal value to me: I could just as well glance down at my Process Explorer CPU icon in the system tray to see FF's progress in initializing.

As for your coding suggestion, thanks, but the effort/benefit ratio doesn't justify it my case. I rather like that my home page (and let me emphasize that it's my browser home page, not a website), basically just a list of links, remains JS-free. I was simply curious about why the behavior changed -- whether by design or by accident.

What I mean is I took the MRE posted, ran four different mozregressions, and the radio was never re-set to the DOM value and always stayed on the last sessionstore value. So I was not able to find any version which would be setting the radio back in this exact MRE (run from the URLs I posted).

If anything specific on your complete HTML+CSS, the file: protocol access, or your profile data per se is a factor, that's not something I can use to track down a regression. Feel free to use the mozregression tool and feed it a clone of your profile to try to find a changeset that would change the observed behavior.

(Maybe there was a wholesale change in loading local documents that influences this, but given I use a different OS there's not much point in me trying to search further, as I can't even reproduce the previous behavior on any version. Sounds more like a bug that got fixed, TBF, if there was inconsistency between local/online/cached/etc. as the behavior makes more sense not defaulting back to values that were overridden after the restore to start with.)

Haven't found any direct changes that would sound relevant, might have been caused by something indirect though.