changes in form state saving/restoring

[Dirk Mueller]

On Don, 09 Jan 2003, Trey Matteson wrote:

> Yes.  We ran into a site that conditionally added a hidden form 
> element based on the existence of a cookie.  It was thus possible to 
> have two different sequences of form elements resulting from the same 
> URL, and the form restore code would get off by one processing the 
> changed page.  The result was that data was restored into the wrong 
> elements, which created havoc. 

I see. I've finally had some time to look at your code, and I think its 
suboptimal for two reasons: 

a) it creatse a O(n^2) algorithm for seaching the matching form element 
state. bad. 

b) it does not localize the form state per <form> element. 


WinIE simply drops the whole form states when the input page changes, even 
if it makes no effect at all. you can easily trigger this by just touching 
hte page. the webserver will re-send the page, and IE wil drop the page from 
the page cache, reuse the one that is sent by the webserver and will not 
apply the saved form state. 

I like this approach, it is trivial to implement, has almost no code 
overhead and is safe (I guess almost no website will by purpose try to break 
WinIEs behaviour in this case). 

NS 4 seems buggy beyond believe in this case, so I don#t bother checking it. 

Mozilla is fairly sophisticated. it seems to save a kind of hash of states, 
indexed by <form_element name> + form_element_type, localized per each 
<form> element. duplicates are okay, it will match them to the form 
elements in order upon restoral (that means if you exchange two otherwise identical form's or form elements 
it will NOT switch the restored state, but apply it in order). 

As soon as there is a mismatch, it will stop applying the rest of the form 
elements in the current <form> block. 

so basically what they do is generate a saved state per each <form> element, 
and apply them by order if they match name+type. 

This is quite overbloated, however it might be convenient for the user as it 
tries really hard to save the previous user input. BTW Mozilla does not 
expose the "https form or password field will not save any form input" 
behaviour WinIE shows. 

The advantage of resembling Mozilla's behaviour is that it would allow us to 
make saveState() a lot faster: it does no longer have to traverse all of the 
document. instead just traverse the (in the document saved) list of 
registered <form> elements. If it matters, .. hmm, thats another story. 

I'm currently quite undecided if we should follow Mozilla or IE here, the 
only thing I'm sure about is that the safari variant is kind of half-baked 
and I'm not really happy with it. If only I'd make up a case where the 
Mozilla behaviour is wrong.. then I would implement WinIE behaviour :-)

comments?


-- 
Dirk