changes in form state saving/restoring

[Trey Matteson]

I was working on Safari on a contract basis at Apple, and that 
engagement has ended.  I'm still reading khtml-devel at kde.org using 
trey at usa.net, and will chime in if I see something go by where I might 
remember something useful.  I made a few comments below.

trey



On Friday, Apr 18, 2003, at 16:26 US/Pacific, Dirk Mueller wrote:

> 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.
>
The current code removes the state strings from the list as they are 
matched.  Since the items are almost always going to be written and 
read in the same order, the performance in practice is linear.  True, 
it could be bad for a large form where the order of the form elements 
was reversed.

> b) it does not localize the form state per <form> element.
>
The remove-as-you-match behavior eliminates this concern for most 
pages, although you could certainly construct a case where a change in 
an early appearing form would leave a piece of state that would be 
accidentally found by an element within a later appearing form.  Seems 
like it would be worth closing this hole, though not an immediately 
critical issue.  Perhaps inserting a marker in the state array for each 
form would be sufficient to line things up at the form granularity.

>
> 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).
>
The only issue I'd raise with this approach is that the topic of when 
to refetch a page from the server has proven to be a complex and 
evolving one for us, as we balance the desired user model for 
back/forward vs. the various http directives vs. the behavior of other 
browsers.  I would have some concern that tying the fairly visible 
decision of whether to restore form state to this subtle decision of 
when to pull the data from the server might lead to a loss of 
predictability for the user.

As a case in point, with the WinIE behavior, instead of receiving our 
original bug of the form state being restored garbled (off by one 
because of the hidden field being removed), we might have received a 
bug about no state being restored at all.  To the user this would 
appear intermittently, based on whether they enter the site with the 
given cookie.

> 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
> _______________________________________________
> Khtml-devel at mail.kde.org
> http://mail.kde.org/mailman/listinfo/khtml-devel
>