User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124) Gecko/20060728 Firefox/126.96.36.199
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52) Gecko/20060728 Firefox/184.108.40.206
I have a page with radiobuttons with different selection statuses which is created dynamically based on data in a database. The page automatically refreshes to keep the page updated with the latest data. When I change the database the selected radiobuttons should be deselected, but they are not.
Steps to Reproduce:
- I create a dynamic page with radiobuttons based on data in a database. This page is refreshed automatically every N seconds to view changes in the database (displayed by another radiobutton being selected).
- I enter the page and all the data is correct
- I update the database and after N seconds the page is automatically refreshed
- The radiobuttons that are selected are exactly the same as before, even though they should have changed due to the changes in the database.
The selected radiobuttons from the first page view are still selected after an automatic refresh of the page.
The radiobuttons on the page should have a completely different selection because the database that provides the selected/deselected status has changed.
I tried adding <meta http-equiv="cache-control" content="no-cache">, <meta http-equiv="pragma" content="no-cache"> and <meta http-equiv="expires" content="-1"> to force no caching of this page, but it didn't help.
In ASP.Net (which is used to generate the page in question) I added the following code to prevent caching, but to no effect:
As a side note, this actually works as it should in Internet Explorer (who would've thought! :P)
Do you have an url or example that shows the problem?
I've created a small page which demonstrates this bug easily.
This page refreshes every 3 seconds and either checks or unchecks the radiobuttons based on data in a database. This data can be changed here:
When the data is changed in updatedb.php one would expect the radiobuttons would change their checked status in viewbug.php, but as is proven, this is not the case.
Note that I've included the cache-control, pragma and expires in the meta tags to try to force Firefox to not use the cached data. Also note that a click on the "Reload the current page" button in the toolbar doesn't update the actual data. To see the updated data you have to place the cursor in the address bar and press [Enter] or the "Go" button.
The problem seems to only affect radiobuttons, as checkboxes update perfectly. It also seems to only affect some kind of internal viewstate, as if I update the HTML source, the page updates with the correct changes, yet the radiobuttons remain unaffected.
I hope this helps.
(In reply to comment #2)
> Note that I've included the cache-control, pragma and expires in the meta tags
> to try to force Firefox to not use the cached data. Also note that a click on
See the notes I added to <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=352848">352848</a> and the discussion in bug <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=202896">202896</a>.
In summary, Firefox ignores no-cache in META tags (from 202896) and I discovered the exact code (re: 352848) that shows that setting EXPIRES to -1 causes it to be ignored. The RFC says that any invalid date should be treated as already expired, but that is not how it functions right now. Until that is fixed, use <META HTTP-EQUIV="Expires" CONTENT="0"> to make it refresh.
If you look at the HTML for 'viewbug.php' you can see that it already has the suggested code (META HTTP-EQUIV="Expires" CONTENT="0"). So the bug is still there even with suggested fix.
Just tested this in Firefox 2.0, and the problem is still evident.
Problem still evident in Firefox 220.127.116.11. Will this bug soon be confirmed?
Problem keeps on persisting. Now confirmed to not be fixed in 18.104.22.168.
*** Bug 430252 has been marked as a duplicate of this bug. ***
The website I posted above to demonstrate this bug has changed location. Use these two instead:
This bug was reported on Firefox 2.x or older, which is no longer supported and will not be receiving any more updates. I strongly suggest that you update to Firefox 3.6.3 or later, update your plugins (flash, adobe, etc.), and retest in a new profile. If you still see the issue with the updated Firefox, please post here. Otherwise, please close as RESOLVED > WORKSFORME
This was just tested on 3.6.3, and the bug is still there.
In a fresh unmodified profile?
Reporter, did you retest in a fresh profile? also, try to update to Firefox 4.
The test cases aren't working. Is this still an issue?
I've had a server update lately and forgot to update the links.
They can now be found here:
This is still an issue in Firefox 4
Glenn, thanks for the prompt reply, I see it as well in Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:7.0a1) Gecko/20110602 Firefox/7.0a1 ID:20110602030223
Possibly a dupe of 183470 although this is a more detailed test case and more specific scenario.
Setting this to confirmed, and we can dupe 183470 to this one if need be.
This has nothing to do with the cache; you're just seeing radio state restoration on reload...
Mounir, could we restrict that to cases when the checked state changed?
And in particular, note that the state of the checkboxes _does_ change, which is how you can tell we're not just reading from cache!
And even ccing mounir. See comment 17? I thought we had another bug on that, but I can't find it...
(In reply to comment #19)
> And even ccing mounir. See comment 17? I thought we had another bug on
> that, but I can't find it...
I'm aware of two bugs that recently pop up related to form restoration but none of them seems similar (bug 644959 and bug 655688, FTR).
So, what you see seems to be done on purpose, see this comment:
It comes from bug 108309 but I really don't understand why the developer did that even after reading the bug twice. It was 10 years ago so there are no tests and no way to ask him directly :(
Fwiw, I think jkeiser does answer his mail.
But I think the reason for that code being that way was to make sure that if one radio in the group was changed we would restore all radios in the group (because otherwise restore could lead to multiple selected radios in the group or whatnot).
Can we keep track of some sort of changed state in the radio group?
(In reply to comment #21)
> Fwiw, I think jkeiser does answer his mail.
Good to know given that he wrote a lot of code I'm working on now ;)
> But I think the reason for that code being that way was to make sure that if
> one radio in the group was changed we would restore all radios in the group
> (because otherwise restore could lead to multiple selected radios in the
> group or whatnot).
That's what I understood but I do not understand how that could be possible: if I select an element in the group, it will de-select another element, thus both elements will have currentValue != defaultValue and will be saved and restored.
What am I missing?
> Can we keep track of some sort of changed state in the radio group?
We actually already have a boolean shared by all the radio elements to know if the group selection has been changed. Though, it will be true even if you go back to the original state.
> What am I missing?
Say I have three radios: A, B, C. First load, A is selected in the markup, B and C are not. I click C. Then I reload; second load B is selected in the markup. If I restore the states of A and C but not B, then both B and C will be selected.... or something.
> Though, it will be true even if you go back to the original state.
That's fine; we just need to know whether the user messed with the value at all.
(In reply to comment #23)
> > What am I missing?
> Say I have three radios: A, B, C. First load, A is selected in the markup,
> B and C are not. I click C. Then I reload; second load B is selected in
> the markup. If I restore the states of A and C but not B, then both B and C
> will be selected.... or something.
Indeed... The hardest part is going to write a test for that. I guess I could use SJS or something. I will see.
Created attachment 537676 [details] [diff] [review]
Tests will come later.
Comment on attachment 537676 [details] [diff] [review]
Created attachment 537877 [details] [diff] [review]
Comment on attachment 537877 [details] [diff] [review]
r=me. I assume you tested that it fails without this patch?
(In reply to comment #28)
> Comment on attachment 537877 [details] [diff] [review] [review]
> r=me. I assume you tested that it fails without this patch?
Glenn, thank you for your perseverance on this bug and I'm sorry it took nearly 5 years to fix it. Firefox 7 is going to have this fix. You will be able to try it with tomorrow's nightly available here: https://nightly.mozilla.org/
Thanks for getting on the case. Even though it took almost five years I'm glad to see you get to all reports eventually.
I downloaded and installed Nightly now (clean installation where no firefox existed before) and I could still see this bug.
You will have to wait until today's build, the nightlies haven't updates yet. wait a few hours until the update releases, and you should see the fix.
I finally got around to test Nightly, and it does indeed seem to be fixed in the version I tried. Thanks for fixing this :)
Mozilla/5.0 (Windows NT 6.1; rv:7.0) Gecko/20100101 Firefox/7.0
Mozilla/5.0 (Windows NT 6.1; rv:9.0a1) Gecko/20110818 Firefox/9.0a1
It seems the issue has been fixed.