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!