Bug 11866 – Hidden form input controls should be reset

• Component: Forms
• Status: RESOLVED WONTFIX

[Kirby White]

<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.)

[Kirby White]

Created attachment 11901 [details]
Test case

This test case is complicated a bit by the need to show what's in the hidden fields.

[David Kilzer (:ddkilzer)]

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?

[Kirby White]

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.

[Kirby White]

Mozilla also lists this as a bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=158209

[Kirby White]

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.

[Darin Adler]

Comment on attachment 11905 [details]
Reset hidden controls, and add input control reset tests

Looks good. r=me

[Mark Rowe (bdash)]

Landed in r18288.  Kirby, can you be sure to use spaces rather than tabs in your changelog entries in future?  Thanks for the patch!

[Kirby White]

(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.

[David Kilzer (:ddkilzer)]

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.

[Jake Logan]

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

[David Kilzer (:ddkilzer)]

(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!

[Jake Logan]

(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...

[David Kilzer (:ddkilzer)]

(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.  :)

[Adele Peterson]

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.

[Adele Peterson]

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.