Bug 8613 - When submitting the second page of a multi-page web form, for input fields also present in the first page, Safari sends the first page's values
Summary: When submitting the second page of a multi-page web form, for input fields al...
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: Forms (show other bugs)
Version: 417.x
Hardware: Mac OS X 10.4
: P2 Major
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-04-26 13:05 PDT by Richard Ward
Modified: 2010-03-16 07:52 PDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Ward 2006-04-26 13:05:20 PDT
Unfortunately, I myself have not been able to reproduce this behavior! However, I have a customer who has a computer center where this behavior is easily reproduced.

Please note this may be related to defect #6733.

I have a CGI script that is capable of logging the data received from and sent to the browser. With the logging feature turned on, I had my customer test a multi-page web form using the Safari browser 417.9.2 on various Mac OS X 10.4 machines in her computer center.

Reading the log file, I see that when the form on the first page is submitted, the Safari browser sends the data correctly and the script sends the browser the second page correctly. Note that many of the hidden input fields on the second page were also present on the first page. Several of these hidden input fields have different values, however.

Reading the log file, I see that when the form on the second page is submitted, the Safari browser sends the correct set of input fields. However, the values sent for the input fields that were also present on the first page are in all cases the first page's values. This suggests the browser retained the input fields from the form on the first page but did not update the fields' values before sending the data for the form on the second page.

Again reading the log file, I see that when the form on the second page is submitted a second time, the Safari browser sends the data correctly. This suggests the browser updates the fields' values after the first submit and before the second submit.

The browser does not exhibit this behavior on the remaining pages. I have not confirmed this but I am guessing the browser needs to be restarted to exhibit this behavior again.

Please note that on the same machines, FireFox 1.5.0.1 does not exhibit this behavior. Also, switching web servers and script variations does not change the behavior of the Safari browser.

Being a developer myself, I realize the importance of providing a test case and appologize for not providing one at this time. If I am able to reproduce the problem myself, I will add a test case to the report.
Comment 1 Joseph Holsten 2010-01-08 15:42:28 PST
Works for me.
Comment 2 Alexey Proskuryakov 2010-01-12 09:51:28 PST
Seems that there isn't anything we can do about this bug without substantial additional information. And chances are that whatever the underlying issue was, it's been fixed since 2006.
Comment 3 benjie 2010-03-16 07:48:48 PDT
At least the latest Chrome 5.0.307.11 beta, and the latest Safari, there is definitely a problem where hidden values of forms are remembered and reloaded incorrectly. That may be related to this problem.

Here is the scenario:

Page A: user is shown a form M, with hidden form field named X whose value is M_x. There is also a form N, with hidden form field named X whose value is N_x.

User POSTS to go to page B.

User hits back button to go back to Page A.

In form M, the value for X is now N_x, not M_x as it should be.

Basically, hidden field values should not be replaced when loading a form, and it seems like the browser is trying to auto fill-in previous values for these fields, and doing so incorrectly, nevertheless.

There are other ways to re-produce this problem, with other sequences of actions, all involving the back button. I will dig more in Bugzilla and file a bug if I don't see a relevant issue, but I think it may be related to this.
Comment 4 benjie 2010-03-16 07:52:23 PDT
The comment I just posted, it's related to 23346. I suspect Richard's problem is also.