url
url copied to clipboard
URLSearchParams and URL [Serializable]
URLSearchParams and URL interfaces are exposed to window and workers but they are not marked as [serializable]. This means that it's not possible to pass them, as objects, to a worker or to a window using postMessage(), but only as strings. Having them serializable (cloneable) would avoid the work-around of sending these objects as strings and recreating them. At the same time, this would allow to store these objects directly into IndexedDB.
cc @inexorabletash @achristensen07 @travisleithead
I'm on the fence whether this is necessary. Seems like there isn't a strong case of passing the objects between browsing contexts, because the input typically arrives in string format already (in each context). Storing in Indexed DB is more interesting, with the possible downside of being bigger (in bytes) to store than the serialized string representation? (Upside is [maybe] performance--not having to re-parse a string into its component parts... though it still happens, we'd just be moving the timing from an explicit Javascript step to having the platform reconstitute the object for you from whatever serialized form is used to store the object internally).
@bakulf can you provide more context on the scenario you're working with? Was this just an unexpected missing feature you ran into, or was there some reason you need to keep the interface object around?
@travisleithead, there is not a particular scenario I'm thinking of, except that currently firefox supports URLSearchParams in postMessaging (everywhere) and in IDB storage.
URL and URLSearchParams interfaces are exposed to workers and window, and it seems reasonable to me that they can be sent directly, instead of parsing the them each time.
@bakulf I think we should probably remove this from Firefox. These objects are primarily meant for mutation, they're not meant to be passed around or stored (use strings instead). Does that seem reasonable?
I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1636761
It could be useful for cloning via structuredClone.
I have created a negative (aka historical) test for this at https://github.com/web-platform-tests/wpt/pull/37994. The rationale is at https://url.spec.whatwg.org/#url-apis-elsewhere. You can pass these around as strings.
(And there also hasn't been any real demand for this functionality.)