changes in form state saving/restoring

[Trey Matteson]

--Apple-Mail-6--560550585
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed

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.

Here is the description of the original bug that led us to make these 
changes:

Go to  http://www.exchangehomes.com/browse.html.  Select, for example, 
Country = England, State = blank, City = London, and click "Search".  
You should get a list of property results.  Click on one of the 
properties to view the details.

Go back. Go back again.  Sometimes the form state will be restored 
wrong, and button titles will be screwy.

I believe that you need to have any cookies for the site cleared before 
these steps, so the first visit is without any cookies but the second 
one has them.  It also relies on return to the page causing a refetch 
of the data, which is dependent on various caching policies.

Let me know if there are more questions, or ideas for a better fix.
trey


On Thursday, January 9, 2003, at 06:26 PM, Dirk Mueller wrote:

> Hi,
>
> any reasons for the QStringList and the lookup by name attibute rather 
> than
> in parsing order ?
>
>
> -- 
> Dirk (received 102 mails today)
> _______________________________________________
> Khtml-devel@mail.kde.org
> http://mail.kde.org/mailman/listinfo/khtml-devel

--Apple-Mail-6--560550585
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=US-ASCII

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.


Here is the description of the original bug that led us to make these
changes:

<fontfamily><param>Geneva</param><smaller>

Go to 
<color><param>0000,0000,FFFF</param>http://www.exchangehomes.com/browse.html.</color> 
Select, for example, Country = England, State = blank, City = London,
and click "Search".  You should get a list of property results.  Click
on one of the properties to view the details.


Go back. Go back again.  Sometimes the form state will be restored
wrong, and button titles will be screwy.</smaller></fontfamily>


I believe that you need to have any cookies for the site cleared
before these steps, so the first visit is without any cookies but the
second one has them.  It also relies on return to the page causing a
refetch of the data, which is dependent on various caching policies.


Let me know if there are more questions, or ideas for a better fix.

trey



On Thursday, January 9, 2003, at 06:26 PM, Dirk Mueller wrote:


<excerpt>Hi, 


any reasons for the QStringList and the lookup by name attibute rather
than 

in parsing order ?



-- 

Dirk (received 102 mails today)

_______________________________________________

Khtml-devel@mail.kde.org

http://mail.kde.org/mailman/listinfo/khtml-devel

</excerpt>
--Apple-Mail-6--560550585--