This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The tentative plan is to make searchParams readonly and the relationship 1:1. However, for Location we need something more complicated due to Location's insanity. Possible ideas for Location's searchParams and URLSearchParams: 1) Not have it 2) Scope lifetime to document (though how does that actually work if you set it for a prior document?) 3) Copy Location's security model (seems way mad) 4) Create an immutable variant Some background: https://bugzilla.mozilla.org/show_bug.cgi?id=1105677
I like the idea of having .searchParams only return the same object until a navigation occurs, or possibly until an origin change occurs, as per https://bugzilla.mozilla.org/show_bug.cgi?id=1082734. People in that thread seem to prefer removing it entirely though; I'm not sure if there's a problem with the changing-return-value idea, or if they just find it too complicated. An alternate approach that seems OK-ish would be to remove .searchParams and add .parseSearchParams(). Then URLSearchParams no longer becomes something that auto-updates its associated url objects, but instead just an in-memory data structure for application/x-www-form-urlencoded manipulation. User code might then look like var searchParams = myURL.parseSearchParams(); searchParams.set('foo', 'bar'); myURL.search = searchParams.toString(); (You could also consider at this point renaming URLSearchParams to FormURLEncodedParams or something else to emphasize its general-purpose nature.)
Solution 4 from comment 0 does not actually work. For now I'm going to specify 1 since I'm not sure how to tackle this for Location. Making it readonly will have to happen separately.
https://github.com/whatwg/url/commit/3a5e8086aff2fe3baa57fcebd1795a16de4f5d16 puts searchParams on its own interface. HTML still needs updating to add it to HTMLAreaElement and HTMLAnchorElement, but not Location.
(In reply to Anne from comment #2) > Making it readonly will have to happen separately. Mostly waiting for https://bugzilla.mozilla.org/show_bug.cgi?id=1174731 to be fixed in Gecko to do that.
That is fixed now, will update the specification next week I think.
https://github.com/whatwg/url/commit/0fdcfbcc58f713d3d804a0cbbe6c1d0cadab2962