Closed Bug 1152657 Opened 10 years ago Closed 9 years ago

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

Categories

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

defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 561586

People

(Reporter: hendry, Unassigned)

Details

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
Status: UNCONFIRMED → NEW
Component: Untriaged → Layout: Form Controls
Ever confirmed: true
OS: Linux → All
Product: Firefox → Core
Hardware: x86_64 → All
Version: 37 Branch → Trunk
Component: Layout: Form Controls → DOM
Olli, do you know who owns this stuff now?
Flags: needinfo?(bugs)
Perhaps Arnaud wants to take a look?
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.
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
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
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)
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).
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: needinfo?(bugs)
Resolution: --- → DUPLICATE
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.