RESOLVED WONTFIX 44436
Cannot complete DHS form AR-11 online due to interactive form control validation (affects other high profile sites)
https://bugs.webkit.org/show_bug.cgi?id=44436
Summary Cannot complete DHS form AR-11 online due to interactive form control validat...
Alexey Proskuryakov
Reported 2010-08-23 10:09:39 PDT
This form has a field with required="no": <div id="fld-MiddleName"><label for="MiddleName">Middle Name</label><span><input name="coaCreate.MiddleName" id="MiddleName" class=" fv-alpha" required="no" maxlength="18" type="text" value=""/></span></div> I'm seeing this problem with Safari 5.0.1 - not with ToT, but that's only due to the fact that interactive form control validation has been disabled in ToT, I think.
Attachments
Patch (3.21 KB, patch)
2011-04-21 09:55 PDT, Kent Tamura
no flags
Patch 2 (3.10 KB, patch)
2012-10-15 01:26 PDT, Kent Tamura
rniwa: review-
Kent Tamura
Comment 1 2011-04-21 09:55:22 PDT
Alexey Proskuryakov
Comment 2 2011-04-21 10:28:43 PDT
Comment on attachment 90548 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=90548&action=review It seems unlikely that this site is the only one affected. Could you please give an overview of working group discussions on this topic? Was is decided that making sites like this not spec-compliant is acceptable? Were there any other examples mentioned? > Source/WebCore/html/HTMLInputElement.cpp:1222 > + // webkit.org/b/44436 It's probably unnecessary to give a bug link - one can get that from svn blame if the information in the comment is not sufficient.
Kent Tamura
Comment 3 2011-04-21 15:37:43 PDT
(In reply to comment #2) > It seems unlikely that this site is the only one affected. > > Could you please give an overview of working group discussions on this topic? Was is decided that making sites like this not spec-compliant is acceptable? Were there any other examples mentioned? The following message introduced some other examples of invalid "required" usages. http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-August/027647.html I remembered Hixie said he could change the attribute name "required" to another, and it's not done. I'm afraid that the new name is also used to other purposes.
Alexey Proskuryakov
Comment 4 2011-04-21 15:54:32 PDT
Thank you! My opinion is that we should probably hold off landing this. The list of affected sites in that e-mail is horrifying, and calls for a more general solution than adding site specific quirks.
Adele Peterson
Comment 5 2011-04-26 16:41:06 PDT
Comment on attachment 90548 [details] Patch r- based on Alexey's last comment.
Ryosuke Niwa
Comment 6 2012-10-11 16:48:47 PDT
http://code.google.com/p/chromium/issues/detail?id=154611 I hit this bug as well. We need to change the spec. accordingly. The current specification is clearly incompatible with the Web.
Kent Tamura
Comment 7 2012-10-15 01:26:14 PDT
Created attachment 168646 [details] Patch 2 rebase
Kent Tamura
Comment 8 2012-10-15 01:30:39 PDT
(In reply to comment #6) > We need to change the spec. accordingly. The current specification is clearly incompatible with the Web. I think changing the spec is too late. Major browsers already implemented "required" attribute, and the attribute name was not renamed though we discussed it in WHATWG. Google Chrome have had the interactive validation feature for 1.5 years, and I haven't heard compatibility issues other than this one. Site-specific quirk is reasonable.
Ryosuke Niwa
Comment 9 2012-10-15 08:31:47 PDT
Comment on attachment 168646 [details] Patch 2 Okay. Sounds like a reasonable solution until we find another site that's broken.
Ian 'Hixie' Hickson
Comment 10 2012-10-15 11:01:26 PDT
FWIW, we did consider this pretty carefully at the time. Any attribute name is going to have _some_ issues, and we decided that required=""'s issues were limited enough that we could live with it. (The cost of having an unobvious attribute name being higher than the cost of a few sites breaking.) Do you think I should put this site-specific hack in the spec? (Or to put it another way: do you think other browsers should also have this hack?)
Tab Atkins
Comment 11 2012-10-15 11:02:48 PDT
(In reply to comment #9) > (From update of attachment 168646 [details]) > Okay. Sounds like a reasonable solution until we find another site that's broken. The first step in dealing with this site *should* be to get our DevRel to try and make them fix it. I know the site has resisted fixing themselves when normal web devs have complained, but it's possible that we can throw more weight at it. We should attempt that *before* adding a quirk for them.
Ian 'Hixie' Hickson
Comment 12 2012-10-15 11:06:33 PDT
Note that this is broken in Firefox too. And Opera.
Ryosuke Niwa
Comment 13 2012-10-15 11:12:10 PDT
This is bad enough that I would expect other browsers to implement the same site-specific quirk at least for now. Leaving the form unusable even for a day is unacceptable because the U.S. government requires non-U.S. citizens to update their address using this form within the 10 days of a move.
Tab Atkins
Comment 14 2012-10-15 11:16:42 PDT
(In reply to comment #13) > This is bad enough that I would expect other browsers to implement the same site-specific quirk at least for now. Leaving the form unusable even for a day is unacceptable because the U.S. government requires non-U.S. citizens to update their address using this form within the 10 days of a move. It's been left "unusable" for months (however long it's been since our support for 'required' hit stable), so taking an additional day (or a week or two) for DevRel to try and fix this properly seems okay.
Ryosuke Niwa
Comment 15 2012-10-15 11:25:01 PDT
(In reply to comment #14) > It's been left "unusable" for months (however long it's been since our support for 'required' hit stable), so taking an additional day (or a week or two) for DevRel to try and fix this properly seems okay. That's insane. The only fix ordinary users can make is to use a browser that doesn't do validation instead. You don't seem to understand how important it is for this form to function correctly for millions of users.
Tab Atkins
Comment 16 2012-10-15 11:30:54 PDT
(In reply to comment #15) > (In reply to comment #14) > > It's been left "unusable" for months (however long it's been since our support for 'required' hit stable), so taking an additional day (or a week or two) for DevRel to try and fix this properly seems okay. > > That's insane. The only fix ordinary users can make is to use a browser that doesn't do validation instead. You don't seem to understand how important it is for this form to function correctly for millions of users. No, I understand how important this form is. I also understand, though, that the form is (a) *not* unusable, just *harder* to use - every field becomes required, and (b) this form has been functioning incorrectly in all modern browsers for *years* (since 2010-08-23, at least), and people have somehow muddled through and still submitted their address changes. This suggests that this is *not* an issue that must be solved RIGHT AWAY (though sooner is better, of course), and we have the luxury of taking a little time to try and solve it *correctly* first, rather than putting a quirk in every browser. I have no problem with this quirk being added *after* we've exhausted the DevRel route to get the site fixed properly. I have a *big* problem with this quirk being the first and only way we try to fix the problem.
Ryosuke Niwa
Comment 17 2012-10-15 11:37:29 PDT
People are forced to use browsers that don't implement validations like Internet Explorer or like me manually modify the DOM in developer tools to work around the issue. And no, you can't muddle through this form on a browser that prevents submission upon validation.
Ryosuke Niwa
Comment 18 2012-10-15 11:42:33 PDT
Also, submitting incorrect information on that form is a crime and could result in the deportation of the person who submitted the form. Hence it's completely unreasonable to expect users to even try "muddling" with the form. Quite frankly, this form not functioning properly is a good enough reason for me to stop using Chrome.
Tab Atkins
Comment 19 2012-10-15 12:41:07 PDT
(In reply to comment #18) > Also, submitting incorrect information on that form is a crime and could result in the deportation of the person who submitted the form. Hence it's completely unreasonable to expect users to even try "muddling" with the form. > > Quite frankly, this form not functioning properly is a good enough reason for me to stop using Chrome. Once again, this has been a problem FOR 2 YEARS. Waiting two weeks for devrel to try and get it fixed properly won't kill anyone. You're making it sound like DHS has been deporting people left and right for the last two years for submitting bad info on this form.
Alexey Proskuryakov
Comment 20 2012-10-15 12:46:33 PDT
Have all the other sites mentioned in e-mail linked from comment 3 (<http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-August/027647.html>) been changed to not use "required"? I agree that switching to Safari or IE to fill out this form should be a fine workaround ;-)
Maciej Stachowiak
Comment 21 2012-10-15 14:20:34 PDT
Comment on attachment 168646 [details] Patch 2 View in context: https://bugs.webkit.org/attachment.cgi?id=168646&action=review > Source/WebCore/html/HTMLInputElement.cpp:1461 > + if (!document()->documentURI().startsWith("https://egov.uscis.gov/", false)) We usually do site-specific hack checks by hostname rather than by URL prefix checking.
Ryosuke Niwa
Comment 22 2012-10-15 18:13:41 PDT
Comment on attachment 168646 [details] Patch 2 (In reply to comment #20) > Have all the other sites mentioned in e-mail linked from comment 3 (<http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-August/027647.html>) been changed to not use "required"? Oops, I missed that. They have NOT been fixed :(
Ian 'Hixie' Hickson
Comment 23 2012-10-17 11:21:48 PDT
Ryosuke Niwa
Comment 24 2013-06-25 21:24:36 PDT
Ryosuke Niwa
Comment 25 2017-11-14 23:12:12 PST
DHS has re-written their website now.
Alexey Proskuryakov
Comment 26 2017-11-17 10:17:50 PST
What about the other sites mentioned in comment 3? This bug tracks all of them.
Ryosuke Niwa
Comment 27 2017-11-18 01:42:31 PST
(In reply to Alexey Proskuryakov from comment #26) > What about the other sites mentioned in comment 3? This bug tracks all of > them. Hm... we should probably file a new bug to track that. By the way, that hyperlink to WHATWG mailing list message is 404 now :(
Note You need to log in before you can comment on or make changes to this bug.