WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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
Details
Formatted Diff
Diff
Patch 2
(3.10 KB, patch)
2012-10-15 01:26 PDT
,
Kent Tamura
rniwa
: review-
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Kent Tamura
Comment 1
2011-04-21 09:55:22 PDT
Created
attachment 90548
[details]
Patch
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
(Reply to that was:
http://lists.w3.org/Archives/Public/public-whatwg-archive/2010Aug/0403.html
)
Ryosuke Niwa
Comment 24
2013-06-25 21:24:36 PDT
Blink added a site specific hack in
https://chromium.googlesource.com/chromium/blink/+/6a881460b939c2ae1ef25bfbe659d6291a18a30a
.
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.
Top of Page
Format For Printing
XML
Clone This Bug