Intent to Implement and Ship: URLSearchParams interface.

101 views
Skip to first unread message

Mike West

unread,
Nov 13, 2015, 9:02:35 AM11/13/15
to Sigbjørn Finne, blink-dev

Contact emails

mk...@chromium.org, sigb...@opera.com


Spec

https://url.spec.whatwg.org/#urlsearchparams


Summary

The URLSearchParams interface allows developers to (shock!) manipulate the search params of a URL. It also provides a mechanism to POST data via `fetch()` with a urlencoded body vs. the multipart body that `FormData` produces.


Motivation

Shipping this feature increases our adherence to the URL spec, and lowers the gap between Chrome and Firefox in terms of the available interfaces, which will make developers happy.


I'm poking at this right now because `URLSearchParams` will enable developers to submit urlencoded data as the body of a POST via `fetch()`. That's a requirement we've heard from developers who are experimenting with the Credential Management API (https://w3c.github.io/webappsec-credential-management/), and this seems like the cleanest way of offering the functionality.


Compatibility Risk

Low. Firefox shipped this interface in 29 (https://bugzilla.mozilla.org/show_bug.cgi?id=887836), and it's a fairly stable part of the URL spec. I've put up a PR to add tests to web platform tests; they pass (with 2 tiny exceptions) in both Firefox and Chrome: https://github.com/w3c/web-platform-tests/pull/2326.


Ongoing technical constraints

I've extracted the core of `URLSearchParams` out of Sigbjorn's excellent patch at https://codereview.chromium.org/143313002/. The integration with `URL` can't happen until Node moves to Oilpan. I'm assured that this will happen Real Soon Now(tm).


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.


OWP launch tracking bug

https://code.google.com/p/chromium/issues/detail?id=303152


Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5632984866619392


Requesting approval to ship?

Yes. I'd like to ship the pieces of this interface that we can ship today, and ship the integration with other interfaces once Oilpan ships.


That is, the `URLSearchParams` interface will exist, and objects can be created and manipulated, and passed to Fetch. The `URL::searchParams` property will not exist until Oilpan ships.


Thanks!


-mike

PhistucK

unread,
Nov 13, 2015, 10:17:40 AM11/13/15
to Mike West, Sigbjørn Finne, blink-dev
While incomplete, its serializer can be used in new URL("http://example.com").search = urlSearchParamsInstance.toString(); (right?) which is great!


PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Mike West

unread,
Nov 13, 2015, 10:27:23 AM11/13/15
to PhistucK, Sigbjørn Finne, blink-dev, Anne van Kesteren
On Fri, Nov 13, 2015 at 4:16 PM, PhistucK <phis...@gmail.com> wrote:
While incomplete, its serializer can be used in new URL("http://example.com").search = urlSearchParamsInstance.toString(); (right?) which is great!

That's correct. `URLSearchParams` will be a complete implementation. It just isn't wired up to URLUtils yet.

On that note, Anne told me earlier today that `URLUtils` is actually obsolete, and that `URLSearchParams` only need to be wired up to `URL`, not to `HTMLAnchorElement`. I think this means that we can implement the integration without waiting for Oilpan, though that will involve a bit of mucking around in Blink, as the two are inextricably linked at the moment.
-mike

Rick Byers

unread,
Nov 13, 2015, 10:48:15 PM11/13/15
to Mike West, PhistucK, Sigbjørn Finne, blink-dev, Anne van Kesteren
LGTM1

TAMURA, Kent

unread,
Nov 15, 2015, 8:02:08 PM11/15/15
to Rick Byers, Mike West, PhistucK, Sigbjørn Finne, blink-dev, Anne van Kesteren
LGTM2.

--
TAMURA Kent
Software Engineer, Google


Philip Jägenstedt

unread,
Nov 16, 2015, 5:32:14 AM11/16/15
to TAMURA, Kent, Rick Byers, Mike West, PhistucK, Sigbjørn Finne, blink-dev, Anne van Kesteren
LGTM3

It seems fine that URL.searchParams isn't implemented yet, since it's apparently only a convenience.

Sigbjorn Finne

unread,
Apr 5, 2016, 2:33:14 PM4/5/16
to Philip Jägenstedt, TAMURA, Kent, Rick Byers, Mike West, PhistucK, blink-dev, Anne van Kesteren
Den 11/16/2015 11:32, Philip Jägenstedt skreiv:
> LGTM3
>
> It seems fine that URL.searchParams isn't implemented yet, since it's
> apparently only a convenience.
>

It's time to support the .searchParams attribute on URL; now made
notionally easier by Oilpan finally being done.

https://codereview.chromium.org/1860623002/ adds it. Should I consider
the LGTMs here to apply to finally ship this attribute also? (For
reference, the original intent:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/grHZDbldP04/JdsoQ169AQAJ
)

--sigbjorn

Philip Jägenstedt

unread,
Apr 5, 2016, 3:13:48 PM4/5/16
to Sigbjorn Finne, TAMURA, Kent, Rick Byers, Mike West, PhistucK, blink-dev, Anne van Kesteren
On Tue, Apr 5, 2016 at 8:32 PM, Sigbjorn Finne <sigb...@opera.com> wrote:
Den 11/16/2015 11:32, Philip Jägenstedt skreiv:
LGTM3

It seems fine that URL.searchParams isn't implemented yet, since it's
apparently only a convenience.


It's time to support the .searchParams attribute on URL; now made notionally easier by Oilpan finally being done.

https://codereview.chromium.org/1860623002/ adds it. Should I consider the LGTMs here to apply to finally ship this attribute also? (For reference, the original intent: https://groups.google.com/a/chromium.org/d/msg/blink-dev/grHZDbldP04/JdsoQ169AQAJ )

I think adding that without another intent sounds fine, but give it a few days in case someone wants to object. Just ping Joe Medley so that he can keep track of which release it ends up in, and maybe he'll want a launch bug or chromestatus entry for that purpose.

Philip
Reply all
Reply to author
Forward
0 new messages