1132142 - Pasting or typing text into an html5 email field does not remove leading/trailing whitespace from the text

Status: REOPENED

(Core :: DOM: Core & HTML, defect, P3)

Description

[Boris Zbarsky [:bzbarsky]]

+++ This bug was initially created as a clone of Bug #657702 +++

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

The rendered HTML5 email field does not accept an email address with whitespace at the beginning or end where it is difficult for the user to see (s)he has entered them by mistake (perhaps during copy and paste)

Steps to Reproduce:
1. write some html5 and run it in firefox
2. enter an email with whitespace at the end
3.


Expected Results:  
that the whitespace would be trimmed before the email was checked for validity

Comment 1

[Boris Zbarsky [:bzbarsky]]

So bug 657702 changed value sanitization to trim off whitespace.  So setting .value to a value with whitespace in it will trim it off.

But typing in the input or pasting into it doesn't seem to trigger value sanitization, nor does blurring it.  Which is correct per spec, but doesn't help with the use cases described in bug 657702.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Interstingly, in Chrome .value on an <input type="email"> that has leading or trailing space strips the spaces.  And so does form submission.  I'm not seeing anything about that in the spec, though maybe I'm just missing something?

Comment 3

[Mounir Lamouri (:mounir)]

If you look at HTMLInputElement::GetValue(), there is a IsExperimentalMobile() check, in which case, the value is sanitized before returning it. The reason is that we want to have a difference between the value being seen and the value being saved. HTMLInputElement isn't really designed that way so it's a small hack that was made. If we want to have a similar behaviour for email, we should probably follow that path. Look at where IsExperiemntalMobileType() is used to see which call sites might need to be changed. This said, it might be interesting to redesign the class to have a notion of visible value and internal value instead of adding a hack on top of a hack.

Comment 4

[Boris Zbarsky [:bzbarsky]]

I'm slightly more interested in the moment in what the spec says here, and whether it needs changes, than in the implementation details on our end (though those are of course important once we get the desired behavior pinned down....).  Mounir, can you explain my observations from comment 2 in spec terms?

Comment 5

[Mounir Lamouri (:mounir)]

In spec term, what you are seeing is the value sanitization algorithm being ran. I do not remember it needing to be run for user inputs. I guess form submission is a side effect (becauses at that point, the value is simply sanitized). It has to be run when .value is set, the type is changed, the form reset or the content attribute value changed. 

Basically, IIRC, the value has to be sanitized when it changes unless when it is a user initiated change.

Comment 6

[Boris Zbarsky [:bzbarsky]]

> In spec term, what you are seeing is the value sanitization algorithm being ran.

On paste?  Or on user typing?  Or on .value _gets_?

Again, in Chrome, if I do this:

  data:text/html,<input type="email">

and then I type "  [e-mail]  " in the input, then the input shows the leading and trailing spaces.  However, getting .value returns "[e-mail]" and submission submits "[e-mail]".  Neither of those has a basis in the spec as far as I can tell, but maybe I'm missing something?

Comment 7

[Mounir Lamouri (:mounir)]

(In reply to Not doing reviews right now from comment #6)
> > In spec term, what you are seeing is the value sanitization algorithm being ran.
> 
> On paste?  Or on user typing?  Or on .value _gets_?

IIRC, the spec requires it when the form is reset, the input element's type changes, its value content attribute is set or its value IDL attribute is set. As far as I know, it is not required on paste, user typing and .value being read.

> Again, in Chrome, if I do this:
> 
>   data:text/html,<input type="email">
> 
> and then I type "  [e-mail]  " in the input, then the input shows the
> leading and trailing spaces.  However, getting .value returns "[e-mail]"
> and submission submits "[e-mail]".  Neither of those has a basis in the
> spec as far as I can tell, but maybe I'm missing something?

I agree. As said in comment 5, I can't remember seeing that behaviour described in the specification too.

Comment 8

[Boris Zbarsky [:bzbarsky]]

OK.  So should I be filing bugs on Chrome (and wontfixing this one) or do we want to change the spec here (and if so how)?

Comment 9

[Frédéric Buclin]

(In reply to Not doing reviews right now from comment #8)
> OK.  So should I be filing bugs on Chrome (and wontfixing this one) or do we
> want to change the spec here (and if so how)?

Oh, please don't wontfix this. type="email" is very useful to force users to enter a valid email address, e.g. when logging into Bugzilla (which is how I discovered this bug in bug 657702 comment 8), but we shouldn't reject the user's input just because his smartphone added some extra leading or trailing whitespaces. And it would be a shame to have to add some JS script to remove them. Bugzilla moved to HTML5 to benefit these extra checks done by the browser itself, not to make the life of developers harder. Bugzilla still removes extra whitespaces when sanitizing the input, but the problem is that the browser refuses to submit the form data if there are extra whitespaces, and so Bugzilla never gets the data. And if we remove type="email", we loose the formatting check done by the browser.

Comment 10

[Mounir Lamouri (:mounir)]

I think that Chrome behaviour makes sense for the reasons stated in comment 9. It is simpler for both users and developers if they don't need to worry about the whitespaces.

Comment 11

[Boris Zbarsky [:bzbarsky]]

OK.  Can you explain to me what the chrome behavior _is_ exactly?  At what points does it perform the sanitization?  Is this specific to email inputs or something it does in general?

Comment 12

[Mounir Lamouri (:mounir)]

My guess is that the difference comes from here:
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/html/forms/TextFieldInputType.cpp&sq=package:chromium&q=convertFromVisibleValue&l=496

EmailInputType::convertFromVisibleValue() calls sanitizeValue() so it will return a value that is stripped from trailing and leading whitespaces.

Disclaimer: I have very little knowledge of Blink's form code.

Comment 13

[Timur Valeev]

And what about "The value sanitization algorithm" from https://html.spec.whatwg.org/multipage/forms.html#e-mail-state-(type=email)?

"Strip line breaks from the value, then strip leading and trailing whitespace from the value."

Looks like is needed to delete leading and trailing whitespaces.

Comment 14

[Boris Zbarsky [:bzbarsky]]

That algorithm never runs when pasting.  Please do see the other comments in this bug.

Mounir, who does know Blink's code well enough to raise the spec issue on this, and can you poke them to do it?

Comment 15

[Timur Valeev]

Yes. Sorry for the wrong comment.

Comment 16

[Mounir Lamouri (:mounir)]

Boris, I've opened https://www.w3.org/Bugs/Public/show_bug.cgi?id=28401 and CC'd Tamura Kent.

Comment 18

[Olli Pettay [:smaug][[e-mail]]]

This seems to be WFM now.

Comment 19

[Olli Pettay [:smaug][[e-mail]]]

Er, sorry, wrong bug.