Last Comment Bug 350022 - Radio checked state is saved/restored even if it has not changed
: Radio checked state is saved/restored even if it has not changed
Status: VERIFIED FIXED
: testcase
Product: Core
Classification: Components
Component: DOM (show other bugs)
: Trunk
: All All
: -- normal with 1 vote (vote)
: mozilla7
Assigned To: Mounir Lamouri (:mounir)
:
Mentors:
: 430252 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-08-24 08:05 PDT by Glenn Thomas Hvidsten
Modified: 2011-08-19 05:01 PDT (History)
9 users (show)
mounir: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
affected
affected
fixed


Attachments
Patch v1 (1.25 KB, patch)
2011-06-06 16:09 PDT, Mounir Lamouri (:mounir)
bzbarsky: review+
Details | Diff | Review
Tests (7.41 KB, patch)
2011-06-07 14:47 PDT, Mounir Lamouri (:mounir)
bzbarsky: review+
Details | Diff | Review

Description Glenn Thomas Hvidsten 2006-08-24 08:05:06 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6

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.

Reproducible: Always

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.
Actual Results:  
The selected radiobuttons from the first page view are still selected after an automatic refresh of the page.

Expected Results:  
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:

Response.Cache.SetCacheability(HttpCacheability.NoCache);

As a side note, this actually works as it should in Internet Explorer (who would've thought! :P)
Comment 1 Martijn Wargers [:mwargers] (not working for Mozilla) 2006-08-24 08:31:15 PDT
Do you have an url or example that shows the problem?
Comment 2 Glenn Thomas Hvidsten 2006-09-01 13:31:16 PDT
I've created a small page which demonstrates this bug easily.

http://whitestone.no/temp/firefoxRefreshBug/viewbug.php

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:

http://whitestone.no/temp/firefoxRefreshBug/updatedb.php

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.
Comment 3 Gerry Daly 2006-09-27 12:45:25 PDT
(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 &lt;META HTTP-EQUIV="Expires" CONTENT="0"&gt; to make it refresh.
Comment 4 Glenn Thomas Hvidsten 2006-10-09 02:06:48 PDT
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.
Comment 5 Glenn Thomas Hvidsten 2006-11-08 04:28:44 PST
Just tested this in Firefox 2.0, and the problem is still evident.
Comment 6 Glenn Thomas Hvidsten 2007-01-12 01:12:15 PST
Problem still evident in Firefox 2.0.0.1. Will this bug soon be confirmed?
Comment 7 Glenn Thomas Hvidsten 2007-06-02 14:08:44 PDT
Problem keeps on persisting. Now confirmed to not be fixed in 2.0.0.4.
Comment 8 gerry 2008-04-23 03:07:15 PDT
*** Bug 430252 has been marked as a duplicate of this bug. ***
Comment 9 Glenn Thomas Hvidsten 2008-04-23 03:43:58 PDT
The website I posted above to demonstrate this bug has changed location. Use these two instead:

http://default.whitestone.no/temp/firefoxRefreshBug/viewbug.php

http://default.whitestone.no/temp/firefoxRefreshBug/updatedb.php
Comment 10 Tyler Downer [:Tyler] 2010-04-23 13:52:19 PDT
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
http://www.mozilla.com
http://support.mozilla.com/kb/Managing+profiles
http://support.mozilla.com/kb/Safe+mode
Comment 11 Glenn Thomas Hvidsten 2010-05-01 11:15:04 PDT
This was just tested on 3.6.3, and the bug is still there.
Comment 12 Tyler Downer [:Tyler] 2010-05-01 11:15:54 PDT
In a fresh unmodified profile?
Comment 13 Tyler Downer [:Tyler] 2011-04-30 06:32:24 PDT
Reporter, did you retest in a fresh profile? also, try to update to Firefox 4.
Comment 14 Stephanie Daugherty [:sdaugherty] 2011-06-04 03:06:17 PDT
The test cases aren't working. Is this still an issue?
Comment 15 Glenn Thomas Hvidsten 2011-06-04 03:59:36 PDT
I've had a server update lately and forgot to update the links.
They can now be found here:

http://default.whitestone.no/temp/firefoxRefreshBug/viewbug.php

http://default.whitestone.no/temp/firefoxRefreshBug/updatedb.php

This is still an issue in Firefox 4
Comment 16 Stephanie Daugherty [:sdaugherty] 2011-06-04 04:49:04 PDT
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.
Comment 17 Boris Zbarsky [:bz] (Out June 25-July 6) 2011-06-06 12:09:27 PDT
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?
Comment 18 Boris Zbarsky [:bz] (Out June 25-July 6) 2011-06-06 12:09:59 PDT
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!
Comment 19 Boris Zbarsky [:bz] (Out June 25-July 6) 2011-06-06 12:11:09 PDT
And even ccing mounir.  See comment 17?  I thought we had another bug on that, but I can't find it...
Comment 20 Mounir Lamouri (:mounir) 2011-06-06 15:09:15 PDT
(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:
https://mxr.mozilla.org/mozilla-central/source/content/html/content/src/nsHTMLInputElement.cpp#3058

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 :(
Comment 21 Boris Zbarsky [:bz] (Out June 25-July 6) 2011-06-06 15:17:47 PDT
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?
Comment 22 Mounir Lamouri (:mounir) 2011-06-06 15:30:07 PDT
(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.
Comment 23 Boris Zbarsky [:bz] (Out June 25-July 6) 2011-06-06 15:38:08 PDT
> 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.
Comment 24 Mounir Lamouri (:mounir) 2011-06-06 15:56:51 PDT
(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.
Comment 25 Mounir Lamouri (:mounir) 2011-06-06 16:09:20 PDT
Created attachment 537676 [details] [diff] [review]
Patch v1

Tests will come later.
Comment 26 Boris Zbarsky [:bz] (Out June 25-July 6) 2011-06-06 20:09:30 PDT
Comment on attachment 537676 [details] [diff] [review]
Patch v1

r=me
Comment 27 Mounir Lamouri (:mounir) 2011-06-07 14:47:57 PDT
Created attachment 537877 [details] [diff] [review]
Tests
Comment 28 Boris Zbarsky [:bz] (Out June 25-July 6) 2011-06-07 14:56:22 PDT
Comment on attachment 537877 [details] [diff] [review]
Tests

r=me.  I assume you tested that it fails without this patch?
Comment 29 Mounir Lamouri (:mounir) 2011-06-07 14:56:59 PDT
(In reply to comment #28)
> Comment on attachment 537877 [details] [diff] [review] [review]
> Tests
> 
> r=me.  I assume you tested that it fails without this patch?

Sure!
Comment 30 Mounir Lamouri (:mounir) 2011-06-08 02:27:55 PDT
Pushed:
http://hg.mozilla.org/mozilla-central/rev/5de9698778f5
http://hg.mozilla.org/mozilla-central/rev/0b370bace7fb

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/
Comment 31 Glenn Thomas Hvidsten 2011-06-09 03:27:43 PDT
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.
Comment 32 Tyler Downer [:Tyler] 2011-06-09 04:29:35 PDT
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.
Comment 33 Glenn Thomas Hvidsten 2011-06-15 08:00:30 PDT
I finally got around to test Nightly, and it does indeed seem to be fixed in the version I tried. Thanks for fixing this :)
Comment 34 Trif Andrei-Alin[:AlinT] 2011-08-19 05:01:37 PDT
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.
Thanks.

Note You need to log in before you can comment on or make changes to this bug.