input type="email" with trailing numbers binds to undefined

[rschooley]

If an email has a trailing number (or -) it passes validation, but results in undefined.

testbed:
http://embed.plnkr.co/QxQmM2o6IS2ulhCvVKDf/preview

scenarios:

• foo@bar.com => console> foo@bar.com
• foo@bar.com2 => console> undefined

verified in angular versions:

• 1.0.7
• 1.0.8
• 1.1.5
• 1.2.0-rc2

Apparently it is legal to end with a number:

• ref: http://www.w3.org/TR/html-markup/input.email.html
• /^[a-zA-Z0-9.!#$%&’+/=?^`{|}~-]+@[a-zA-Z0-9-]+(?:.[a-zA-Z0-9-]+)_$/

And after looking at that regex a - also causes the same undefined behavior

[petebacondarwin]

This seems a more up to date (or WIP in fact) reference: http://www.w3.org/TR/html5/forms.html#valid-e-mail-address
In here it also allows short top level domains that can end in digits but cannot start or end in hyphens

email         = 1*( atext / "." ) "@" label *( "." label )
label         = let-dig [ [ ldh-str ] let-dig ]  ; limited to a length of 63 characters by RFC 1034 section 3.5
atext         = < as defined in RFC 5322 section 3.2.3 >
let-dig       = < as defined in RFC 1034 section 3.5 >
ldh-str       = < as defined in RFC 1034 section 3.5 >

It states that this is a:

"willful violation" of RFC 5322, which defines a syntax for e-mail addresses that is simultaneously too strict (before the "@" character), too vague (after the "@" character), and too lax (allowing comments, whitespace characters, and quoted strings in manners unfamiliar to most users) to be of practical use here.

The regex given there is

/^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$/

Currently using this regex breaks a unit test that claims that

expect(EMAIL_REGEXP.test('a@B.c')).toBe(false);

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?

[cqr]

@rschooley When you say it "passes validation", are you referring to the spec or something in Angular validating correctly? Or the browser itself?

[rschooley]

@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.

[cqr]

@rschooley The browser also validates "-@-", which is clearly not a valid email address. Would it make sense to add a browser-level validation for input type="email" inputs that would cause it to fail validation in the same situations that angular returns undefined?

[rschooley]

@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.

[cqr]

I'll write the pull request if a team member thinks that it would be worthwhile.

[cqr]

@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

[Narretz]

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.
http://plnkr.co/edit/7Qtwqx73GC7OTe01xTbf?p=preview

[caitp]

A domain label ending with, or beginning with a - should be invalid, and there is a PR to make this invalid (#6026), however I kind of want to wait for Chromium v34 to ship so that this matches Chromium's behaviour.

[Narretz]

@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?

[caitp]

@Narretz the regexp was updated today --- we allow domains which begin/end with numbers, because the RFC does

[caitp]

Let me see if this is still an issue today, since we've updated this... We might be able to close this issue

[Narretz]

yeah, that's why I ask. Trailing numbers are also allowed by the regex, it seems

[caitp]

http://plnkr.co/edit/zSjAOgVTWfs37caMjD9J?p=preview looks like we're good here

[caitp]

Closed by af6f943

[caitp]

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