Closed Bug 21767 Opened 25 years ago Closed 25 years ago

Form values not reset on page reload

Categories

(Core :: Layout: Form Controls, defect, P3)

Product:
Core
Component:
Layout: Form Controls
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: neilconway, Assigned: radha)

References

Details

Attachments

(2 files)

test case
120 bytes, text/html
Details
Diffs for nsSessionHistory.cpp
1.58 KB, patch
Details | Diff | Splinter Review 
Here is a test case that exhibits the bug:
--
<html>
  <body>
<form>
  <input type="text" value="test">
</form>
test2
</body>
</html>
--
When you change the values of both test fields, and refresh the page (using the
refresh button), 'test2' is (usually) changed, but the 'test' (inside the form
tag) remains the same

Bug found using Seamonkey 991214 on Debian GNU/Linux 2.2, glibc 2.1.2
Assignee: rickg → pollmann
Enjoy.
Component: HTML Element → HTML Form Controls
Hardware: PC → All
Summary: Form Value=xxx, Not Refreshed → Form values not reset on page reload
The test case is a bit unclear to me.  Is "test2" really supposed to be "<input
type=text value=test2>"?

I tried this with today's build.  Pulled up the test case, changed both text
fields and hit refresh.  I ovserveded that both text inputs were set to the
altered values instead of the default values of "test1" and "test2".  I'll
attach the test case.

In this case, it seems to me that the expected result would be that forms reset
back to their default value.  I'm CC'ing Nisheeth and Radha on this one because
it could be that either the form destroy/recreate logic or session history is
capturing than restoring this information when it probably shouldn't.
Attached file test case — 

    
    

    
  
Sorry for the unclean test case.



In the test page I provided, "test2" was

supposed to be "as is" - text to show

that the page has been changed and

reloaded properly, but the "text" field of

the form has not changed.



For my

test case above:



Load test case. Then change "test" to "changed", and change

"test2" to "also

changed". Reload. The regular text ("also changed") should be

properly updated,

but the "text" field in the form still shows the old value

("test").



I just tested it now with M12 on Linux and the bug still exists.

    
    

    
  
I see...  First load up the html file in the browser.  While it is being
displayed by the browser, edit the html file itself with a text editor and save
the edited version.  Press reload on the browser.  The newly edited values
should appear in the browser.  Right now the form value isn't updated.  Please
ignore the test case I posted   :)

Radha, does session history save and restore state on a page reload?  If so,
might that be what's causing this problem?  Thanks!
Status: NEW → ASSIGNED
Target Milestone: M13

    
    

    
  
I think Session History restores history state on reload, which it probably
shouldn't. I'll take a look at this.

    
  
Assignee: pollmann → radha
Status: ASSIGNED → NEW

    
    

    
  
Reassigning to Radha per her comments.  Thanks for taking a look at this, and
feel free to reassign it back to me if it turns out to be something else!

    
    

    
  
I changed session history so that it won't restore the history state when a
reload is done. when I tested this test case with my fix, after I press the
reload, both the form text element(test1) and the regular text element (test2)
lose their changes and come back to their default values.

From the discussions
above it looks like test2 s'd have retained the changed value. Did I get it right?

session history doesn't have control on individual element's history object.
Eric, would you know how to handle this?

I tried to run this test case in 4.x. The second text element (test2) doesn't
even show up in the 4.x browser.

Attached are amy patch for nsSessionHistory.cpp

    
    

    
  
Sounds good to me.  Sorry for the confusion Radha, I didn't understand what Neil
was trying to do so I made a bad test case. Both test1 and test2 should be
returned to the value - nothing should be stored in session history for a page
reload.

To verify this bug as fixed, use Neil's original test case:

<html>
  <body>
<form>
  <input type="text" value="test">
</form>
test2
</body>
</html>

Save this to a file on your machine then open it up in the browser.  While it is
being viewed in your browser, edit the html file on your local machine to change
the values of Text1 and Text2, something like:

<html>
  <body>
<form>
  <input type="text" value="test changed">
</form>
test2 changed
</body>
</html>

save the edited file then click reload on the browser.  The page you see should
have the updated values that you just saved, not the original file.  I didn't
understand this and went and created that bad test case, please ignore my test
case.  :)

Sounds like you're doing the right thing to me!
Status: NEW → ASSIGNED

    
    

    
  
Got it. Shall check in my chnages. Going to mark r=pollmann in the checkin
comment.

    
    

    
  
Sounds okay to me, thanks!
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED

    
    

    
  
fix checked in. Please verify.

    
    

    
  
Fixed in the Jabn 20th build.

Status: RESOLVED → VERIFIED

    
    

    
  
*** Bug 82477 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 84686 has been marked as a duplicate of this bug. ***

    
    

    
  
Recommend REOPENING this bug.  I found a testcase for which Moz0.9.2 milestone
build does not reset the designated form value.

I was about to submit the following bug; thankfully I searched for dupes first.
-- quote --
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:0.9.2) Gecko/20010628
BuildID: Mozilla/5.0 (Windows; U; Win95; en-US; rv:0.9.2) Gecko/20010628

Mozilla ignores the contents of a textarea set within the HTML document, after
the page reloads. In some cases (such as filling in a bug report) is this
helpful. However, when a JavaScript acts onload of the document to automatically
modify the textarea, the results can skew quite badly.



Reproducible: Always
Steps to Reproduce:
1. Visit http://jslab.on.openave.net/tashort.php .
2. Let the page finish loading.
3. Reload the page.

Actual Results: The inline JavaScript modified the previously modified textarea
contents, instead of a fresh copy.

Expected Results: The textarea value should have reset automatically, for the
JavaScript to exactly reproduce the results earlier given.

The complete source code for tashort.php is contained in tashort.php, in the
textarea. As you can see, it uses a PHP script to preset the textarea's
contents, so as far as the browser is concerned, it is receiving the same HTML
document.

There is a workaround for JavaScript, using the statement:

document.forms[x].reset()

at the beginning of the function the onload event handler calls.
-- end quote --

This situation may be a duplicate of bug #46845.  A quote from that bug:

------- Additional Comments From Scott Gifford 2000-10-14 00:07 -------

As of 2000101021, form elements which have no default values are left as is, but
elements which have default values are reset to their default values.

-- end quote --



    
    

    
  
Please don't reopen. The other bug mentioned is currently reopened.

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: