Summary: | Hidden form input controls should be reset | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Kirby White <KwhiteRight> | ||||||
Component: | Forms | Assignee: | 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
Kirby White
2006-12-18 10:35:02 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.
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? 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. Mozilla also lists this as a bug: https://bugzilla.mozilla.org/show_bug.cgi?id=158209 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 on attachment 11905 [details]
Reset hidden controls, and add input control reset tests
Looks good. r=me
Landed in r18288. Kirby, can you be sure to use spaces rather than tabs in your changelog entries in future? Thanks for the patch! (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. 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. 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 (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! (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... (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. :) 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. 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. |