64415 - Button labels reset on back and history.go(0)

Status: VERIFIED FIXED

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

Description

[Tim Powell]

Using Mozilla build 2000121404 on NT.

This bug was prompted by bug 55988.

Button labels 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/labels would maintain state so that going back let's you return to a 
page exactly as it was when you left.

In case you're curious, IE5 and Netscape4 both reset the button labels to the 
default when returning to or reloading the page.

I'll add a testcase to demonstrate this bug.

Comment 1

[Tim Powell]

Attachment: Test case that demonstrates button labels being reset

Comment 2

[Johnny Stenback (:jst)]

Reassigning to rods who usually deals with pres-state issues like this.

Comment 3

[rods (gone)]

pollmann, this is easy enough to add, what does the spec say?

Comment 4

[Eric Pollmann]

Hmm, this smells a lot like that select bug - whether to preserve the list of
options or not!  :)  In that case, at least Nav 4.x does this, so there is some
precedent.  In this case...  Hmm...  Neither Nav 4.x nor IE 5.x preserves the
label value.  :S

Unfortunately, I just fixed this bug in my tree when fixing bug 55988, because
the hidden input is implemented by the button frame, hmm, puts me in a bit of a
dilemma.  :)  Rod, what is your opinion on this one?

My thoughts:
 Against:
   no spec says how session history should behave, so use past precedent
   nav 4.x does not preserve label value
   ie 5.x does not preserve label value
 For:
   the value of a button is less likely to be 'appended' to, which protects it
from the select/options list problem where the list could just grow and grow
   it's a feature!  :)

Comment 5

[Tim Powell]

For me this is simply a question of consistency. ALL other form elements 
maintain state when you leave the page and come back: input elements, 
selection, textareas, hidden fields (well, they will soon just like IE5). 
Button is the only input type form element that does not maintain its current 
value. Why would this be desireable? 

Staying with past precedent is only a good idea if it is beneficial behavior. 
There's no benefit for the user when the page changes state simply by leaving 
it and coming back. I'd classify IE5 and NS4's behavior here as a bug (same 
with the hidden field behavior of NS4). The vast majority of the time, the 
button's label will not be changed, so making it maintain state will cause no 
harm. If a button's label is changed, however, it would be desireable for that 
change to be maintained. This is especially important for dynamic web apps that 
need a way to keep the back button from causing bad side effects. While we'll 
have to use workarounds for the other browsers, I'd rather see Mozilla set the 
precedent for them and be consistent.

Comment 6

[waqar]

Adding Mr. DOM

Comment 7

[Eric Pollmann]

Rod, I can check this in with some other fixes in my tree (they are all related
to saving and restoring frame state), should I take this bug?

Comment 8

[Eric Pollmann]

Fix checked in.  To verify, view the test case, click "Change the Labels"
button, click "Go Home" link, then click the back button.  The buttons should
still have the new labels.

Comment 9

[Prashant Desale]

Reopening bug because it does not work with reloading the page with 
"javascript:history.go(0)". 
In existing testcase follow all the steps, but at the end if you click 
"javascript:history.go(0)" then it does not work. Button labes do not change 
back to default values.

"javascript:history.go(0)" itself works fine on other pages, so there is no 
problem with that. I may be wrong reopening, but this is what I can conclude 
right now. Please mark resolved if problem is somewhere else.

Comment 10

[Kevin McCluskey (gone)]

Reassigning to pollmann.

Comment 11

[Eric Pollmann]

Reload not restoring state is a more general problem.  This is true of all
stateful frames - scroll position, and form inputs, and can be seen by simply
scrolling halfway down a page and clicking the Reload button.

I've debugged this somewhat and it looks like this is because when reloading, we
capture frame state twice - once when we should, then once again right at the
beginning of the document loading.  This second capture overwrites the first and
erases all state.

This may be already filed as a bug.  If not, it should be filed as a new bug.
I'll do a search.  In the meantime, re-closing this one as it is fixed in the
general case.

Comment 12

[Eric Pollmann]

The bug crept in sometime between 2000/11/20 and 2000/12/05, which leaves a lot
of suspect changes:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=11%2F20%2F2000&maxdate=12%2F05%2F2000&cvsroot=%2Fcvsroot

Comment 13

[Prashant Desale]

In that case I'll verify this one. About reload problem, if there are I'll check 
if there is any existing bug or will report seperate one.