1865674 - Input of type email is regarded as invalid (for css and form validation) while being automatically fixed for JS and form submission

Status: NEW

(Core :: DOM: Forms, defect)

Description

[sfouret]

Steps to reproduce:

• Have a form with input of type email (<input type="email")
• Have css showing input:invalid (input:invalid {outline: 2px solid red;})
• Enter an email with spaces around its value : " [e-mail] "

Actual results:

Firefox consider the email as invalid:

• pseudo-class :invalid is being used
• Impossible to submit form without 'novalidate'

Expected results:

Actual result is inconsistent with javascript behavior and the value submitted when putting novalidate in the form. Due to inconsistent behavior, the value can be fixed in doing onkeyup="value=value"

Firefox should consider the input as valid:

• css pseudo-class in use should be :valid
• form submission should be possible

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::CSS Parsing and Computation' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Emilio Cobos Álvarez [:emilio]]

Attachment: test-case.

Comment 3

[Emilio Cobos Álvarez [:emilio]]

I can repro, it seems it claims that there's a type mismatch, which indicates that this code is what's returning true incorrectly.

bug 583610 is what introduced the whitespace trimming in email validation.

Comment 4

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

https://html.spec.whatwg.org/multipage/input.html#email-state-(type=email)

The value sanitization algorithm is as follows: Strip newlines from the value, then strip leading and trailing ASCII whitespace from the value.

Yeah, ignoring the leading space is the valid behavior. The method mentioned by Emilio uses GetNonFileValueInternal which will return raw value of TextEditor or default value as-is. So, it checks non-sanitized value.