Closed Bug 55988 Opened 24 years ago Closed 23 years ago

hidden fields reset on back and history.go(0)

Categories

(Core :: DOM: Core & HTML, defect, P3)

Product:
Core
Component:
DOM: Core & HTML
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla0.8.1

People

(Reporter: tpowellmoz, Assigned: pollmann)

Details

(Keywords: dom0)

Attachments

(4 files)

Created a test case that demonstrates the hidden field reset (based on code above)
1.07 KB, text/html
Details
fix 1
3.65 KB, patch
Details | Diff | Splinter Review
fix 2 (save hidden state but NOT button state)
3.77 KB, patch
Details | Diff | Splinter Review
patch 3 - stores original value as member of frame
5.40 KB, patch
Details | Diff | Splinter Review 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m18) Gecko/20001009
BuildID:    2000100917

Input type=hidden fields do not maintain state unlike all other input types when
going back or reloading the page. This doesn't make sense. I'd think all fields
would maintain state.

What I'm looking for is a way to maintain state when going back and forth from a
page. Since JavaScript variables are reset each page load (which is logical) I
was hoping to use hidden fields. This works great in IE4/5. Unfortunately,
Netscape 4 also loses state for hidden fields. It looks like this was fixed for
Bug #413 for MozClassic. Another similar bug is Bug #247 that has worksforme. I
can work around the bug in Netscape 4 using (text) fields in a form in a hidden
layer (which act like normal text fields and are not reset). Ideally Mozilla
would maintain state and restore hidden fields when returning to the page just
like IE5.


Reproducible: Always
Steps to Reproduce:
The following code demonstrates the problem:

<html>
<head>
<title>Hidden field lose values</title>
<script language="JavaScript">
function showHiddenVal()
{
	alert("Hidden val: " + document.frm.HideMe.value)		
}
function setHiddenVal(str)
{
	document.frm.HideMe.value = str;			
}
</script>
</head>
<body onLoad="showHiddenVal()">
<form name="frm">
<input type="hidden" name="HideMe" value="">
</form>

<a href="/">Go Home</a><p>
Edit the text field and set the hidden value. Click a link away from the page
and click the back button. Or use the Javascript <a
href="javascript:history.go(0)">history.go(0)</a> You'll see the text value is
the same, but the hidden field's value has been reset.<p>

<input type="button" value="Set hidden"
onclick="setHiddenVal('1');showHiddenVal()"><input type="button" value="Show
hidden" onclick="showHiddenVal()"><br> <input type="text" value="Change this
text...">
</form>
</body>
</html>


Actual Results:  The text field is restored to the value it had when you left
the page, but the hidden field is reset.

Expected Results:  The hidden field should also have its value restored to what
it had when you left the page.
Pollmann agreed to look into this problem, reassigning.
Assignee: jst → pollmann
setting bug status to New
Status: UNCONFIRMED → NEW
Ever confirmed: true
Set milestone to mozilla0.9
Target Milestone: --- → mozilla0.9
Attached patch fix 1 — — Splinter Review 

    
    

    
  
The above fix makes hidden inputs (implemented strangely enough by
nsGfxButtonControlFrame) into nsIStatefulFrames, and adds methods to save and
restore state for them.  Currently it also saves and restores state for button
values, which would preserve changes in the label on a button.  Not sure if this
is desired behaviour or not?  :)
Status: NEW → ASSIGNED
OS: Windows NT → All
Hardware: PC → All

    
    

    
  
I'd say that it should maintain the state of button labels as well as hidden 
fields. This provides consistency with user expectations when going back to a 
page (The page shouldn't change between when you leave it and when you come 
back.) I logged bug 64415 about this very problem.

    
  
Target Milestone: mozilla0.9 → mozilla0.8

    
    

    
  
Fix checked in.  To verify, click "Set hidden" button, note what the hidden
value is, click "Go Home" link, click back button.  The hidden value should be
the same as the one you noted earlier.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED

    
    

    
  
Reopening because this is still broken for both back and history.go(0) on build
2001020804.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
    

    
  
Okay, somehow, I think I tested before checking in the fixes for optimizing when
we save state (we only do it if .value is different than .defaultValue which is
*never* true for hidden or button inputs)

I'll fix this in 0.9!
Target Milestone: mozilla0.8 → mozilla0.9
Keywords: dom0

    
    

    
  
Setting milestone to mozilla0.8.1
Target Milestone: mozilla0.9 → mozilla0.8.1

    
    

    
  
Attaching another patch.  This patch takes into account that the default value
of a form control may change (in the case of hidden inputs, this is equivalent
to the value changing).  When the value changes, we store the original default
value in a member variable of the form control frame.  At state saving time
(when we leave the page), we compare this original value with the current state.
 If they differ, we store the state in Session History.
Status: REOPENED → ASSIGNED

    
    

    
  
Checked in a simplified patch per super/reviews.  To verify, click "Set hidden"
button, note what the hidden value is, click "Go Home" link, click back button.
 The hidden value should be the same as the one you noted earlier.

Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → FIXED

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: