Bug 44436 - Cannot complete DHS form AR-11 online due to interactive form control validation (affects other high profile sites)
Summary: Cannot complete DHS form AR-11 online due to interactive form control validat...
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: Forms (show other bugs)
Version: 528+ (Nightly build)
Hardware: Macintosh OS X 10.6
: P2 Normal
Assignee: Kent Tamura
URL: https://egov.uscis.gov/crisgwi/go?act...
Keywords:
Depends on:
Blocks: 28649 59019
  Show dependency treegraph
 
Reported: 2010-08-23 10:09 PDT by Alexey Proskuryakov
Modified: 2017-11-18 01:42 PST (History)
9 users (show)

See Also:


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

Note You need to log in before you can comment on or make changes to this bug.
Description Alexey Proskuryakov 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.
Comment 1 Kent Tamura 2011-04-21 09:55:22 PDT
Created attachment 90548 [details]
Patch
Comment 2 Alexey Proskuryakov 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.
Comment 3 Kent Tamura 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.
Comment 4 Alexey Proskuryakov 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.
Comment 5 Adele Peterson 2011-04-26 16:41:06 PDT
Comment on attachment 90548 [details]
Patch

r- based on Alexey's last comment.
Comment 6 Ryosuke Niwa 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.
Comment 7 Kent Tamura 2012-10-15 01:26:14 PDT
Created attachment 168646 [details]
Patch 2

rebase
Comment 8 Kent Tamura 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.
Comment 9 Ryosuke Niwa 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.
Comment 10 Ian 'Hixie' Hickson 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?)
Comment 11 Tab Atkins 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.
Comment 12 Ian 'Hixie' Hickson 2012-10-15 11:06:33 PDT
Note that this is broken in Firefox too. And Opera.
Comment 13 Ryosuke Niwa 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.
Comment 14 Tab Atkins 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.
Comment 15 Ryosuke Niwa 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.
Comment 16 Tab Atkins 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.
Comment 17 Ryosuke Niwa 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.
Comment 18 Ryosuke Niwa 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.
Comment 19 Tab Atkins 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.
Comment 20 Alexey Proskuryakov 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 ;-)
Comment 21 Maciej Stachowiak 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.
Comment 22 Ryosuke Niwa 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 :(
Comment 23 Ian 'Hixie' Hickson 2012-10-17 11:21:48 PDT
(Reply to that was: http://lists.w3.org/Archives/Public/public-whatwg-archive/2010Aug/0403.html )
Comment 24 Ryosuke Niwa 2013-06-25 21:24:36 PDT
Blink added a site specific hack in https://chromium.googlesource.com/chromium/blink/+/6a881460b939c2ae1ef25bfbe659d6291a18a30a.
Comment 25 Ryosuke Niwa 2017-11-14 23:12:12 PST
DHS has re-written their website now.
Comment 26 Alexey Proskuryakov 2017-11-17 10:17:50 PST
What about the other sites mentioned in comment 3? This bug tracks all of them.
Comment 27 Ryosuke Niwa 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 :(