<input type='url'> should check URLs according to URL Standard
Categories
(Core :: DOM: Forms, defect)
Tracking
()
People
(Reporter: mounir, Unassigned)
References
(Depends on 1 open bug, Blocks 1 open bug, )
Details
(Keywords: html5, parity-chrome)
Attachments
(2 files, 1 obsolete file)
Comment 1•14 years ago
|
||
Reporter | ||
Updated•14 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Comment 3•4 years ago
|
||
This might be good to look into once we implement the URL Standard better.
Updated•2 years ago
|
Comment 4•10 months ago
|
||
Our URL standard implementation is now really good, with 97% on the interop score - we're aiming for 99-100 by the end of the year.
Looking at the example code in https://html.spec.whatwg.org/multipage/input.html#url-state-(type%3Durl) in both Chrome and Firefox, I see Chrome's implementation is really close to the reference image - while Firefox doesn't provide suggestions at all.
Clearing priority so this issue gets retriaged.
Comment 5•10 months ago
•
|
||
This isn't really about the suggestions UI, but about validating URL strings. I made a testcase based on https://searchfox.org/mozilla-central/rev/2c3d657cbba5484ccac44443c4417baed7b5fafb/testing/web-platform/tests/conformance-checkers/tools/url.py and it looks like we're still allowing a number of things that shouldn't be allowed (missing // after the scheme for special schemes, non-digit in port, whitespace in various pieces, …).
Comment 6•10 months ago
|
||
Comment 7•10 months ago
|
||
To be clear, all the inputs in attachment 9377381 [details] should be green I think.
Comment 8•10 months ago
|
||
The value sanitization algorithm for type=url
does strip newlines, so the values containing newlines are actually valid.
Comment 9•10 months ago
|
||
Description
•