Summary: | Cannot complete DHS form AR-11 online due to interactive form control validation (affects other high profile sites) | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Alexey Proskuryakov <ap> | ||||||
Component: | Forms | Assignee: | Kent Tamura <tkent> | ||||||
Status: | RESOLVED WONTFIX | ||||||||
Severity: | Normal | CC: | ian, mifenton, mjs, m.kurz+webkitbugs, rniwa, syoichi, tabatkins, tkent, webkit.review.bot | ||||||
Priority: | P2 | ||||||||
Version: | 528+ (Nightly build) | ||||||||
Hardware: | Mac | ||||||||
OS: | OS X 10.6 | ||||||||
URL: | https://egov.uscis.gov/crisgwi/go?action=coa.cr.Residence | ||||||||
Bug Depends on: | |||||||||
Bug Blocks: | 28649, 59019 | ||||||||
Attachments: |
|
Description
Alexey Proskuryakov
2010-08-23 10:09:39 PDT
Created attachment 90548 [details]
Patch
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. (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. 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. Comment on attachment 90548 [details]
Patch
r- based on Alexey's last comment.
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. Created attachment 168646 [details]
Patch 2
rebase
(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. Comment on attachment 168646 [details]
Patch 2
Okay. Sounds like a reasonable solution until we find another site that's broken.
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?) (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. Note that this is broken in Firefox too. And Opera. 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. (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. (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. (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. 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. 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. (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. 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 ;-) 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. 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 :( (Reply to that was: http://lists.w3.org/Archives/Public/public-whatwg-archive/2010Aug/0403.html ) Blink added a site specific hack in https://chromium.googlesource.com/chromium/blink/+/6a881460b939c2ae1ef25bfbe659d6291a18a30a. DHS has re-written their website now. What about the other sites mentioned in comment 3? This bug tracks all of them. (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 :( |