-
Notifications
You must be signed in to change notification settings - Fork 27.4k
input type="email" with trailing numbers binds to undefined #4275
Comments
This seems a more up to date (or WIP in fact) reference: http://www.w3.org/TR/html5/forms.html#valid-e-mail-address
It states that this is a:
The regex given there is
Currently using this regex breaks a unit test that claims that
I guess it would be best to follow this version though in the long run, even if it allows emails that appear not to be valid currently? |
@rschooley When you say it "passes validation", are you referring to the spec or something in Angular validating correctly? Or the browser itself? |
@chrisrhoden The validation I am referring to is at the browser level; trailing numbers or dashes pass through to angular which then returns an undefined at the scope level. If you get a minute, check out the plunkr above, you can see the behavior. |
@rschooley The browser also validates "-@-", which is clearly not a valid email address. Would it make sense to add a browser-level validation for |
@chrisrhoden My thoughts are W3C specs and vendor implementations are typically a mess, so it doesn't surprise me that we get strange behavior in edge cases like this. The browser has handed Angular something that is says is valid, but we know looks invalid. On the other hand, as a user, something I put into the field passed validation, but that value didn't come out the other side. An extra validation in this case that matches Angular's expectations sounds like a good solution, as long as it's documented that we aren't matching the exact (ever changing) html5 spec from W3C. Maybe allowing developers to override the pattern with an attribute would call this out. |
I'll write the pull request if a team member thinks that it would be worthwhile. |
@rschooley it looks like the recommended way forward is to disable the browser validation of inputs and rely on angular's validation. As for custom pattern behavior, the ngPattern option is available http://docs.angularjs.org/api/ng.directive:input.email |
In 1.2.10, the regex was changed to Chromium's. That means since then both foo@bar.com2 and foo@bar.com- are valid for angular. Funnily enough, in Firefox foo@bar.com- is marked as invalid by the browser. |
A domain label ending with, or beginning with a |
@caitp What about numbers in the domain name, are they valid, or differently phrased, should this issue stay open, because the regex will eventually be updated to cover this case? |
@Narretz the regexp was updated today --- we allow domains which begin/end with numbers, because the RFC does |
Let me see if this is still an issue today, since we've updated this... We might be able to close this issue |
yeah, that's why I ask. Trailing numbers are also allowed by the regex, it seems |
http://plnkr.co/edit/zSjAOgVTWfs37caMjD9J?p=preview looks like we're good here |
Closed by af6f943 |
It might be good to add a test case including trailing numbers, because I don't think there was one in that PR since that wasn't the main focus. If anyone wants to add one, that would be fine |
If an email has a trailing number (or
-
) it passes validation, but results in undefined.testbed:
http://embed.plnkr.co/QxQmM2o6IS2ulhCvVKDf/preview
scenarios:
verified in angular versions:
Apparently it is legal to end with a number:
And after looking at that regex a
-
also causes the sameundefined
behaviorThe text was updated successfully, but these errors were encountered: