849611 - Validation on <input type="email"> should trim first instead of failing

Status: NEW

(Core :: DOM: Forms, defect)

Description

[Micha]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 Firefox/19.0
Build ID: 20130219173943

Steps to reproduce:

I have a form that requires the user to input their email address. This form is used for login and the email address is used for identification. In an attempt to make the form HTLM5 enabled, I changed the input type from type="text" to type="email". This triggers HTML form validation. Furthermore, to support older browsers, there are also a JS based validation and a server-side validation. Both the JS and server side validation apply a trim function to remove leading and trailing white spaces from user input. This includes email addresses as well. For email addresses, trailing or leading white spaces are not valid and can be safely trimmed.


Actual results:

Firefox 19 on Linux and 18 on Windows fail to validate the email address if there are leading or trailing white spaces. The form cannot be submitted. The user is asked to enter a valid email address.


Expected results:

Firefox should either trim the white spaces it self or at least internally before validation. The average user just receives the message to enter a valid email address, which they apparently did and cannot figure out that the leading or trailing white space may cause the problem. In a perfect world, all users would know this, but in reality, the web developer has to check it and apply appropriate measures. In this case, trimming is fine. A more descriptive error message would be another step. But if someone can tell a program/website to figure out what exactly is wrong with the data, they may also tell the program/website to correct the data without bugging the user.

Comment 1

[Lucas Malor (mail: c6kfnkn2uc AT snkmail DOT c0m)]

From WHATWG site:
"The value sanitization algorithm is as follows: Strip line breaks from the value, then strip leading and trailing whitespace from the value."
http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#e-mail-state-%28type=email%29

Confirming.

Comment 2

[Mounir Lamouri (:mounir)]

Unfortunately, we show the input's value for the moment so we would have to automatically remove spaces while the user is typing to make that behaviour working. The other solution would be to have a workaround and allow spaces around the value but it seems that the disagreement is minor enough to make this not too much of a problem.

As soon as bug 805049 is fixed, we should be able to sanitize the value without showing the actual sanitized value but simply the one typed by the user but still have the sanitized value as the internal value (ie. returned by .value).

FWIW, the specification changed on us and our behaviour is the previous one.

Comment 3

[stratease]

I just had the same issue in our production environment. At first I thought there was a validation error. After inspecting I realized there was just a space or newline at the end of the value the user entered. 

At the very least there should be some way to visually inspect that there's a leading/trailing space being detected if the validation is failing. It's not clear when the validation tooltip is presented.

Comment 4

[Gene Wood [:gene]]

I just encountered this error in the Mozilla Single Sign On form.

Comment 5

[Sven P]

I came across this bug as I can still reproduce it with current FF 125. In comment #2 (11 years ago) it was stated that this bugs depends on solving bug 805049 first. I understand this. On the other hand, for the other bug there has been a patch for 5 years now rotting in this bug tracker. As the HTML spec (referred in comment 1) is still valid, I would appreciate it if we could fix this issue now. What is missing? How can I help to get it done?