Closed Bug 726758 Opened 13 years ago Closed 13 years ago

<input type=email> validation fails on addresses with whitespace at beginning or end

Categories

(Firefox :: Untriaged, defect)

Product:
Firefox
Component:
Untriaged
Version:
13 Branch
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: matt, Unassigned)

Details

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0a1) Gecko/20120210 Firefox/13.0a1 Build ID: 20120210040207 Steps to reproduce: A document with simply these lines: <!doctype html> <input type=email> does not allow an email address with a space at either the beginning or the end. The HTML5 spec says that the sanitization (sanitation?) process must include stripping leading and trailing whitespace from the value. http://dev.w3.org/html5/spec/Overview.html#e-mail-state-type-email Entering an email address with a space at the beginning or the end causes the box to have a red border when blurred, indicating an invalid email address. I tested this with the latest Firefox UX nightly. Actual results: Email box had red border. Expected results: Not actually sure, I guess the whitespace characters should simply be removed.
(In reply to Robert Longson from comment #1) > That's what the html5 specification calls for doesn't it? > http://www.whatwg.org/specs/web-apps/current-work/#e-mail-state- > %28type=email%29 and > http://www.whatwg.org/specs/web-apps/current-work/#valid-e-mail-address Then at what point is the whitespace stripped? What is the point of that line in the spec? <quote>The value sanitization algorithm is as follows: Strip line breaks from the value, then strip leading and trailing whitespace from the value.</quote>
According to the specification that happens when the multiple attribute is added/removed.
My apologies, it appears I've wasted everyones' time. I'm clearly not experienced at reading spec documents.
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.