Bug 11866

Summary: Hidden form input controls should be reset
Product: WebKit Reporter: Kirby White <KwhiteRight>
Component: FormsAssignee: Nobody <webkit-unassigned>
Status: RESOLVED WONTFIX    
Severity: Normal CC: darin, ddkilzer, ian, j, mrowe
Priority: P2 Keywords: HasReduction
Version: 420+   
Hardware: All   
OS: All   
Attachments:
Description Flags
Test case
none
Reset hidden controls, and add input control reset tests darin: review+

Description Kirby White 2006-12-18 10:35:02 PST
<input type="hidden"> form controls are not reset by reset buttons, reset input controls, or the form.reset() method.  They should be restored to their default values when the form is reset.  (It's not completely described in a spec anywhere, but that's what IE does, so chances are good that there are pages depending on it.)
Comment 1 Kirby White 2006-12-18 10:40:41 PST
Created attachment 11901 [details]
Test case

This test case is complicated a bit by the need to show what's in the hidden fields.
Comment 2 David Kilzer (:ddkilzer) 2006-12-18 11:03:10 PST
Interestingly enough, MSIE 6 does reset the hidden fields, while neither Firefox 1.5.0.8 nor 2.0 resets the hidden fields.

I wonder what Opera 9, OmniWeb 5.5 and shipping Safari 2.0.4 do?
Comment 3 Kirby White 2006-12-18 11:38:43 PST
Safari 2.0.4, Opera 9.10 for Mac, and OmniWeb 5.5.0 all ignore reset() for hidden fields.

iCab 3.0.3 resets the empty field, but puts junk into the one that should hold "Default Value", and then gets completely muddled and can't set either field's value properly (with the "Modify..." button in the attached test case) again.
Comment 4 Kirby White 2006-12-18 12:36:37 PST
Mozilla also lists this as a bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=158209
Comment 5 Kirby White 2006-12-18 14:55:49 PST
Created attachment 11905 [details]
Reset hidden controls, and add input control reset tests

I believe this fix is simple and safe.

The patch also includes test cases for resetting other types of input form controls.  I deliberately broke resetting and verified that it's not covered by any other cases.
Comment 6 Darin Adler 2006-12-18 15:16:38 PST
Comment on attachment 11905 [details]
Reset hidden controls, and add input control reset tests

Looks good. r=me
Comment 7 Mark Rowe (bdash) 2006-12-18 15:36:40 PST
Landed in r18288.  Kirby, can you be sure to use spaces rather than tabs in your changelog entries in future?  Thanks for the patch!
Comment 8 Kirby White 2006-12-18 15:51:54 PST
(In reply to comment #7)
> Kirby, can you be sure to use spaces rather than tabs in
> your changelog entries in future?

Yes, sorry about that.  Thanks for the landing.
Comment 9 David Kilzer (:ddkilzer) 2006-12-18 16:36:26 PST
This patch caused a layout test regression in fast/forms/input-value.html.

http://build.webkit.org/results/post-commit-powerpc-mac-os-x/4737/

See Bug 11870.
Comment 10 Jake Logan 2007-03-16 16:53:13 PDT
This 'fix' breaks code in the SAP environment we are working on. SAP has two code branches, one for Firefox and one for IE. We have directed SAP to check the user-agent and pass Safari code designed for Firefox, which has allowed the environment to function correctly. We have also told SAP that WebKit strives to adheres to the W3C spec and generally behaves like Firefox, not IE. This case is an exception to that rule. 

This patch causes the entire SAP environment to fail - it causes the main tabs of the application to break leaving the application completely unusable.

It will be very difficult or impossible to convince SAP to change the code in thier Firefox branch to behave like IE code, considering this will break thier code for Firefox. It occurs to me that WebKit should stay in sync with Firefox until the Mozilla guys get around to modifying the behavior to work like IE. Ours may not be the only regression related to this issue.

Can you please consider reverting this change until Firefox makes the same change?

Best regards,

Jake
Comment 11 David Kilzer (:ddkilzer) 2007-03-16 19:18:15 PDT
(In reply to comment #10)
> This 'fix' breaks code in the SAP environment we are working on.

Jake, please file a new Bugzilla bug to track this issue, but reference this bug in it.  Make the bug P1 so that it gets noticed (and since it's a regression for SAP, add the "Regression" keyword).  Thanks!

Comment 12 Jake Logan 2007-03-19 15:50:32 PDT
(In reply to comment #11)
> (In reply to comment #10)
> > This 'fix' breaks code in the SAP environment we are working on.
> 
> Jake, please file a new Bugzilla bug to track this issue, but reference this
> bug in it.  Make the bug P1 so that it gets noticed (and since it's a
> regression for SAP, add the "Regression" keyword).  Thanks!
> 

Regression bug: http://bugs.webkit.org/show_bug.cgi?id=13121

Thanks for your help David. Can you tell me where to add the 'Regression' keyword? I don't see a place for that...
Comment 13 David Kilzer (:ddkilzer) 2007-03-19 18:17:14 PDT
(In reply to comment #12)
> Thanks for your help David. Can you tell me where to add the 'Regression'
> keyword? I don't see a place for that...

In the "Keywords" field on the bug, you just type "Regression" and then submit the bug again.  :)

Comment 14 Adele Peterson 2007-05-29 17:47:48 PDT
Rolled out this change because it caused:

<rdar://problem/5213039> REGRESSION: Wells Fargo registration page returns blank

Since all browsers update the value attribute when setting the value, it doesn't really make sense to reset.  Its true that IE does support resetting these controls, but in this case, it doesn't really make sense to have another place to store an alternate version of the value.

Comment 15 Adele Peterson 2007-05-29 17:49:27 PDT
At this point, I'm resolving this as "won't fix".  If we find any real-world sites that rely on being able to reset hidden inputs, then we can reopen this bug.

Also, if you want to reproduce the regression, follow these steps:

Go to:
https://www.wellsfargo.com/app2k/nga/authentication/register
Enter registration details.
After pressing Register, the returned page is empty.