[Webkit-unassigned] [Bug 23346] Restore form control values to a wrong form

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sat Apr 3 11:37:46 PDT 2010


--- Comment #30 from benjie at lablife.org  2010-04-03 11:37:44 PST ---

Thanks for the update on your plan.

There is a problem with what you described, not including @value. Any CGI
infrastructure where the action depends on the value of a hidden CGI variable,
will be broken when user hits back button.

Consider this: form A on page X, when user is logged in, has CGI variable named
action, value set to "add". User goes from X to next page, user session times
out, hits back button, lands on page X, but form A is replaced by server with
form B: with CGI variable named action, value set to "login".  But WebKit would
replace the value from "login" to "add".

If you are not going to take the hash of the entire form, you should at least
include hidden values in the hash. 

I wonder if there's a different way to consider this problem. We've been
struggling with what's the best solution if the page is reloaded. No matter
what we are guessing what the server's intention is.

Perhaps there should be two separate behaviors. First, if when user hits the
back button, WebKit does NOT reload the page, but instead loads the page from
cache, and also does not fire off JS again, then you can auto-fill forms using
exactly the same technique as implemented in the existing code base.

Second, if when user hits the back button, WebKit does RELOAD from server, then
after loading the page, any JS hooks will fire off as well. In this case, we
shouldn't worry about things like hidden values and type=submit input element
values. In fact, in this case, perhaps the auto-fill should ONLY handle values
that users can type. So in this case, what Kent proposed would work, if
augmented with not changing values of any input element that the user cannot
enter via keyboard.

Does that make sense at all?

Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

More information about the webkit-unassigned mailing list