1152657 - required type=url submits on incomplete URL http://

Status: RESOLVED DUPLICATE of bug 561586

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

Description

[Kai Hendry]

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

Steps to reproduce:

Put in an invalid non-absolute url like:
* http:
* http://
* https://

And submit the form http://skel.dabase.com/


Actual results:

An invalid non-absolute URL was submitted


Expected results:

It should be flagged for completion, like Chrome does:
http://s.natalian.org/2015-04-09/1428561468_1054x1058.png

Comment 1

[Boris Zbarsky [:bzbarsky]]

Olli, do you know who owns this stuff now?

Comment 2

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

Perhaps Arnaud wants to take a look?

Comment 3

[Arnaud Bienner]

Actually, I didn't worked on this input type, but, yeah, why not having a look: I haven't been very active lately :)
I'll be very busy in the next 10 days, but after that, I can try to have a look if it can wait.

But to answer your question, I don't know who owns all the form related stuff since Mounir left Mozilla.

Comment 4

[Arnaud Bienner]

Just a quick note: according to the W3C [1], this a URI is defined by this RFC [2] which contains the following:
   IRI            = scheme ":" ihier-part [ "?" iquery ]
                         [ "#" ifragment ]

   ihier-part     = "//" iauthority ipath-abempty
                  / ipath-absolute
                  / ipath-rootless
                  / ipath-empty

so it seems it is allowed to have an empty string, according to W3C.

*However* WhatWG [3] refers to their own definition for a valid URL [4], which implies having a non-empty path after the scheme (since it has to specify the host, or for the "file" scheme, a path starting with '/')

(I just had quick look, so maybe I missed some things)

IIRC we follow WhatWG specification, so should probably change our behavior. Also (more importantly) I'm not sure it makes sense for a user to send a URL containing containing an empty path. But on the other hand, I don't like the idea of unnecessarily restricting user's input.

I will have a deeper look later.

[1]: http://www.w3.org/TR/html-markup/input.url.html
[2]: http://tools.ietf.org/html/rfc3987#section-3.1
[3]: https://developers.whatwg.org/urls.html#valid-url
[4]: https://url.spec.whatwg.org/#url-syntax

Comment 5

[Arnaud Bienner]

My previous comment was incorrect.
I refer to [1] as the W3C specification, but this an obsolete document.
[2] seems to be the good one, and it refers to [3] for the specification of URLs, which states "Developers of Web browsers are advised to keep abreast of the latest URL developments by tracking the progress of https://url.spec.whatwg.org/."

Long story short: W3C or WHATWG doesn't matter: they both refer to the same URL definition.

And while [3] refers to [RFC3986] and [RFC3987] (which says "http://" is a valid URL AFAICT), they also refer to https://url.spec.whatwg.org/ which says "http://" isn't a valid URL.

[1]: http://www.w3.org/TR/html-markup/input.url.html
[2]: http://www.w3.org/TR/html5/forms.html#url-state-%28type=url%29
[3]: http://www.w3.org/TR/html5/references.html#refsURL

Comment 6

[Arnaud Bienner]

And in HTMLInputElement.cpp Mounir stated anyway we are missing some checks for <input type="url">

http://hg.mozilla.org/mozilla-central/annotate/5d61714cf5c3/dom/html/HTMLInputElement.cpp#l6366

See bug 561586 (which may just be a duplicate of this one, but it is still not clear to me if we need to strictly follow RFC 3986 and 3987)

Comment 7

[Arnaud Bienner]

I think we can just close this bug as a duplicate of bug 561586.
I will try to have a look at bug 561586 (and bug 19313).