[blink-dev] Intent to Ship: Add value argument to URLSearchParams's has() and delete()

[Debadree Chatterjee]

Contact emails
debadree...@gmail.com 

Explainer
None

Specification
https://url.spec.whatwg.org/#dom-urlsearchparams-has

Summary
This feature adds the ability to pass a `value` argument to URLSearchParams's 
has() and delete() methods which allow for deleting tuples stored in 
URLSearchParams either by the `name` parameter or by the combination of `name` 
and `value`


Blink component
Blink 

TAG review
None

TAG review status
Not applicable

Risks


Interoperability and Compatibility
Compatibility with existing websites were tested by means of a Counter in 
chromium, ref: https://github.com/whatwg/url/pull/735#issuecomment-1441503315 
and no significant chances of breaking were found

Gecko: No signal

WebKit: No signal

Web developers: Has Shipped (https://github.com/WebKit/WebKit/pull/13500)

Other signals:

WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it 
has potentially high risk for Android WebView-based applications?
None expected


Debuggability
None

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

Is this feature fully tested by web-platform-tests 
?
Yes

Flag name


Requires code in //chrome?
False

Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1442916

Estimated milestones
No milestones specified


Anticipated spec changes
Open questions about a feature may be a source of future web compat or interop 
issues. Please list open issues (e.g. links to known github issues in the 
project for the feature specification) whose resolution may introduce web 
compat/interop risk (e.g., changing to naming or structure of the API in a 
non-backward-compatible way).
None Expected

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5147732899004416

Links to previous Intent discussions
Intent to prototype: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CFBE060E-9D1C-4B8D-A4FB-B0279D73E6F4%40gmail.com

This intent message was generated by Chrome Platform Status 
.

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/A73025EA-70D7-4818-9CFF-AE14B48875F0%40gmail.com.

Re: [blink-dev] Intent to Ship: Add value argument to URLSearchParams's has() and delete()

[Philip Jägenstedt]

It looks like this was spec'd in https://github.com/whatwg/url/pull/735,
with participation from Chromium and WebKit folks.
https://bugzilla.mozilla.org/show_bug.cgi?id=1831587 was filed for Gecko,
but there's no clear position. Would you mind filing an issue at
https://github.com/mozilla/standards-positions/issues/new to ensure Mozilla
is aware this happening?

https://chromestatus.com/metrics/feature/timeline/popularity/4478 is pretty
low, but was any analysis done of sites that reach this use counter? It's
honestly higher usage than I'd expect for an argument that didn't do
anything before, so likely the value passed doesn't make sense and will
result in the parameter not being deleted for delete(), which could be a
problem. What can you say about usage in the wild here?

+Andreu Botella 

On Fri, May 12, 2023 at 9:30 AM Debadree Chatterjee 
wrote:

> Contact emailsdebadree...@gmail.com
>
> ExplainerNone
>
> Specificationhttps://url.spec.whatwg.org/#dom-urlsearchparams-has
>
> Summary
>
> This feature adds the ability to pass a `value` argument to
> URLSearchParams's has() and delete() methods which allow for deleting
> tuples stored in URLSearchParams either by the `name` parameter or by the
> combination of `name` and `value`
>
>
> Blink componentBlink
> 
>
> TAG reviewNone
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> Compatibility with existing websites were tested by means of a Counter in
> chromium, ref:
> https://github.com/whatwg/url/pull/735#issuecomment-1441503315 and no
> significant chances of breaking were found
>
> *Gecko*: No signal
>
> *WebKit*: No signal
>
> *Web developers*: Has Shipped (https://github.com/WebKit/WebKit/pull/13500
> )
>
> *Other signals*:
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?
>
> None expected
>
>
> Debuggability
>
> None
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?
> Yes
>
> Is this feature fully tested by web-platform-tests
> 
> ?
> Yes
>
> Flag name
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1442916
>
> Estimated milestones
>
> No milestones specified
>
>
> Anticipated spec changes
>
> Open questions about a feature may be a source of future web compat or
> interop issues. Please list open issues (e.g. links to known github issues
> in the project for the feature specification) whose resolution may
> introduce web compat/interop risk (e.g., changing to naming or structure of
> the API in a non-backward-compatible way).
> None Expected
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5147732899004416
>
> Links to previous Intent discussionsIntent to prototype:
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CFBE060E-9D1C-4B8D-A4FB-B0279D73E6F4%40gmail.com
>
> This intent message was generated by Chrome Platform Status
> .
>
> --
> 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+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/A73025EA-70D7-4818-9CFF-AE14B48875F0%40gmail.com
> 
> .
>

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYfbrySi0ZuYD%2B3GpQARyZyxNasY2d3wR6L6yjFUep%2B6-A%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Add value argument to URLSearchParams's has() and delete()

[Debadree Chatterjee]

Hey!

> to ensure Mozilla is aware this happening?

I am filing an issue for this

> What can you say about usage in the wild here?

In regards to this I believe no more data was collected, one example of 
usage where two arguments may be used was pointed out 
here https://github.com/whatwg/url/pull/735#issuecomment-1397898382 other 
than this I havent been able to come up with another example maybe it is 
possible to collect data on the type of argument being used in those sites? 
is that possible and would that be helpful here?

On Friday, May 12, 2023 at 2:09:21 PM UTC+5:30 Philip Jägenstedt wrote:

> It looks like this was spec'd in https://github.com/whatwg/url/pull/735, 
> with participation from Chromium and WebKit folks. 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1831587 was filed for Gecko, 
> but there's no clear position. Would you mind filing an issue at 
> https://github.com/mozilla/standards-positions/issues/new to ensure 
> Mozilla is aware this happening?
>
> https://chromestatus.com/metrics/feature/timeline/popularity/4478 is 
> pretty low, but was any analysis done of sites that reach this use counter? 
> It's honestly higher usage than I'd expect for an argument that didn't do 
> anything before, so likely the value passed doesn't make sense and will 
> result in the parameter not being deleted for delete(), which could be a 
> problem. What can you say about usage in the wild here?
>
> +Andreu Botella 
>
> On Fri, May 12, 2023 at 9:30 AM Debadree Chatterjee  
> wrote:
>
>> Contact emailsdebad...@gmail.com
>>
>> ExplainerNone
>>
>> Specificationhttps://url.spec.whatwg.org/#dom-urlsearchparams-has
>>
>> Summary
>>
>> This feature adds the ability to pass a `value` argument to 
>> URLSearchParams's has() and delete() methods which allow for deleting 
>> tuples stored in URLSearchParams either by the `name` parameter or by the 
>> combination of `name` and `value`
>>
>>
>> Blink componentBlink 
>> 
>>
>> TAG reviewNone
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> Compatibility with existing websites were tested by means of a Counter in 
>> chromium, ref: 
>> https://github.com/whatwg/url/pull/735#issuecomment-1441503315 and no 
>> significant chances of breaking were found
>>
>> *Gecko*: No signal
>>
>> *WebKit*: No signal
>>
>> *Web developers*: Has Shipped (
>> https://github.com/WebKit/WebKit/pull/13500)
>>
>> *Other signals*:
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that 
>> it has potentially high risk for Android WebView-based applications?
>>
>> None expected
>>
>>
>> Debuggability
>>
>> None
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac, 
>> Linux, Chrome OS, Android, and Android WebView)?
>> Yes
>>
>> Is this feature fully tested by web-platform-tests 
>> 
>> ?
>> Yes
>>
>> Flag name
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1442916
>>
>> Estimated milestones
>>
>> No milestones specified
>>
>>
>> Anticipated spec changes
>>
>> Open questions about a feature may be a source of future web compat or 
>> interop issues. Please list open issues (e.g. links to known github issues 
>> in the project for the feature specification) whose resolution may 
>> introduce web compat/interop risk (e.g., changing to naming or structure of 
>> the API in a non-backward-compatible way).
>> None Expected
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5147732899004416
>>
>> Links to previous Intent discussionsIntent to prototype: 
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CFBE060E-9D1C-4B8D-A4FB-B0279D73E6F4%40gmail.com
>>
>> This intent message was generated by Chrome Platform Status 
>> .
>>
>> -- 
>> 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.
>> To view this discussion on the web visit 
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/A73025EA-70D7-4818-9CFF-AE14B48875F0%40gmail.com
>>  
>> 
>> .
>>
>

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6adac07b-7eae-42cf-ba66-d25e1f9446a5n%40chromium.org.

Re: [blink-dev] Intent to Ship: Add value argument to URLSearchParams's has() and delete()

[Philip Jägenstedt]

On Fri, May 12, 2023 at 11:57 AM Debadree Chatterjee 
wrote:

> Hey!
>
> > to ensure Mozilla is aware this happening?
>
> I am filing an issue for this
>

Thanks! Can you link it here when filed?


> > What can you say about usage in the wild here?
>
> In regards to this I believe no more data was collected, one example of
> usage where two arguments may be used was pointed out here
> https://github.com/whatwg/url/pull/735#issuecomment-1397898382 other than
> this I havent been able to come up with another example maybe it is
> possible to collect data on the type of argument being used in those sites?
> is that possible and would that be helpful here?
>

It may be helpful yes, as it might reveal a usage pattern that will
actually break the site in a serious way.
https://chromestatus.com/metrics/feature/timeline/popularity/4478 lists 20
example URLs at the bottom of the page:

https://jornalmassa.com.br/
https://lyubercy.rus-buket.ru/
https://balashiha.rus-buket.ru/
https://astrahan.rus-buket.ru/
https://barnaul.rus-buket.ru/
https://chekhov.rus-buket.ru/
https://courses.arnos.gr/
https://www.skoleforeningen.org/
https://maisonyoko.com/
https://orel.rus-buket.ru/
https://krasnodar.rus-buket.ru/
https://ag-web.completemaths.com/
https://chelyabinsk.rus-buket.ru/
https://rus-buket.ru/
https://voronezh.rus-buket.ru/
https://wiwin.de/
https://www.arnos.gr/
https://crossfitdespentes.fr/
https://tutor.completemaths.com/
https://omsk.rus-buket.ru/

Can you go through these and see what the extra argument to has() and
delete() are and what the effect of the change would be on those site? The
rus-buket.ru sites are obviously a group, so checking one of them will
suffice.

Best regards,
Philip

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYeYTNf%3D%3DsPezUJiAeXeOWnxwK7q%2BwVvoSeevKWvAdieHA%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Add value argument to URLSearchParams's has() and delete()

[PhistucK]

I would imagine code like ["parameter1",
"parameter2"].map(searchParameters.has.bind(searchParameters)) in which
case it will start to return falses because the second parameter (index in
the .map callback) will now be the value. This kind of code is always
fragile, though, so kind of... Tough luck to the developer.

☆*PhistucK*


On Fri, May 12, 2023 at 9:39 AM Philip Jägenstedt 
wrote:

> It looks like this was spec'd in https://github.com/whatwg/url/pull/735,
> with participation from Chromium and WebKit folks.
> https://bugzilla.mozilla.org/show_bug.cgi?id=1831587 was filed for Gecko,
> but there's no clear position. Would you mind filing an issue at
> https://github.com/mozilla/standards-positions/issues/new to ensure
> Mozilla is aware this happening?
>
> https://chromestatus.com/metrics/feature/timeline/popularity/4478 is
> pretty low, but was any analysis done of sites that reach this use counter?
> It's honestly higher usage than I'd expect for an argument that didn't do
> anything before, so likely the value passed doesn't make sense and will
> result in the parameter not being deleted for delete(), which could be a
> problem. What can you say about usage in the wild here?
>
> +Andreu Botella 
>
> On Fri, May 12, 2023 at 9:30 AM Debadree Chatterjee 
> wrote:
>
>> Contact emailsdebadree...@gmail.com
>>
>> ExplainerNone
>>
>> Specificationhttps://url.spec.whatwg.org/#dom-urlsearchparams-has
>>
>> Summary
>>
>> This feature adds the ability to pass a `value` argument to
>> URLSearchParams's has() and delete() methods which allow for deleting
>> tuples stored in URLSearchParams either by the `name` parameter or by the
>> combination of `name` and `value`
>>
>>
>> Blink componentBlink
>> 
>>
>> TAG reviewNone
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> Compatibility with existing websites were tested by means of a Counter in
>> chromium, ref:
>> https://github.com/whatwg/url/pull/735#issuecomment-1441503315 and no
>> significant chances of breaking were found
>>
>> *Gecko*: No signal
>>
>> *WebKit*: No signal
>>
>> *Web developers*: Has Shipped (
>> https://github.com/WebKit/WebKit/pull/13500)
>>
>> *Other signals*:
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>> None expected
>>
>>
>> Debuggability
>>
>> None
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?
>> Yes
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>> Yes
>>
>> Flag name
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1442916
>>
>> Estimated milestones
>>
>> No milestones specified
>>
>>
>> Anticipated spec changes
>>
>> Open questions about a feature may be a source of future web compat or
>> interop issues. Please list open issues (e.g. links to known github issues
>> in the project for the feature specification) whose resolution may
>> introduce web compat/interop risk (e.g., changing to naming or structure of
>> the API in a non-backward-compatible way).
>> None Expected
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5147732899004416
>>
>> Links to previous Intent discussionsIntent to prototype:
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CFBE060E-9D1C-4B8D-A4FB-B0279D73E6F4%40gmail.com
>>
>> This intent message was generated by Chrome Platform Status
>> .
>>
>> --
>> 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+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/A73025EA-70D7-4818-9CFF-AE14B48875F0%40gmail.com
>> 
>> .
>>
> --
> 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+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYfbrySi0ZuYD%2B3GpQARyZyxNasY2d3wR6L6yjFUep%2B6-A%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-

Re: [blink-dev] Intent to Ship: Add value argument to URLSearchParams's has() and delete()

[Debadree Chatterjee]

Hey!

I have filed the Mozilla issue 
here https://github.com/mozilla/standards-positions/issues/801

In regards to the given urls to investigate the URLs themselves are all 
landing pages, I may be wrong I believe the metrics counter would be 
capturing usages within different user flows no? We wouldn't know what 
those are, any methods you suggest on how to investigate? Just went through 
the page source of some of the URLs the JS loaded in the landing pages 
themselves doesn't seem to be problematic

Yours Sincerely,
Debadree
On Friday, May 12, 2023 at 5:48:33 PM UTC+5:30 PhistucK wrote:

> I would imagine code like ["parameter1", 
> "parameter2"].map(searchParameters.has.bind(searchParameters)) in which 
> case it will start to return falses because the second parameter (index 
> in the .map callback) will now be the value. This kind of code is always 
> fragile, though, so kind of... Tough luck to the developer.
>
> ☆*PhistucK*
>
>
> On Fri, May 12, 2023 at 9:39 AM Philip Jägenstedt  
> wrote:
>
>> It looks like this was spec'd in https://github.com/whatwg/url/pull/735, 
>> with participation from Chromium and WebKit folks. 
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1831587 was filed for 
>> Gecko, but there's no clear position. Would you mind filing an issue at 
>> https://github.com/mozilla/standards-positions/issues/new to ensure 
>> Mozilla is aware this happening?
>>
>> https://chromestatus.com/metrics/feature/timeline/popularity/4478 is 
>> pretty low, but was any analysis done of sites that reach this use counter? 
>> It's honestly higher usage than I'd expect for an argument that didn't do 
>> anything before, so likely the value passed doesn't make sense and will 
>> result in the parameter not being deleted for delete(), which could be a 
>> problem. What can you say about usage in the wild here?
>>
>> +Andreu Botella 
>>
>> On Fri, May 12, 2023 at 9:30 AM Debadree Chatterjee  
>> wrote:
>>
>>> Contact emailsdebad...@gmail.com
>>>
>>> ExplainerNone
>>>
>>> Specificationhttps://url.spec.whatwg.org/#dom-urlsearchparams-has
>>>
>>> Summary
>>>
>>> This feature adds the ability to pass a `value` argument to 
>>> URLSearchParams's has() and delete() methods which allow for deleting 
>>> tuples stored in URLSearchParams either by the `name` parameter or by the 
>>> combination of `name` and `value`
>>>
>>>
>>> Blink componentBlink 
>>> 
>>>
>>> TAG reviewNone
>>>
>>> TAG review statusNot applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> Compatibility with existing websites were tested by means of a Counter 
>>> in chromium, ref: 
>>> https://github.com/whatwg/url/pull/735#issuecomment-1441503315 and no 
>>> significant chances of breaking were found
>>>
>>> *Gecko*: No signal
>>>
>>> *WebKit*: No signal
>>>
>>> *Web developers*: Has Shipped (
>>> https://github.com/WebKit/WebKit/pull/13500)
>>>
>>> *Other signals*:
>>>
>>> WebView application risks
>>>
>>> Does this intent deprecate or change behavior of existing APIs, such 
>>> that it has potentially high risk for Android WebView-based applications?
>>>
>>> None expected
>>>
>>>
>>> Debuggability
>>>
>>> None
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac, 
>>> Linux, Chrome OS, Android, and Android WebView)?
>>> Yes
>>>
>>> Is this feature fully tested by web-platform-tests 
>>> 
>>> ?
>>> Yes
>>>
>>> Flag name
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bug
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1442916
>>>
>>> Estimated milestones
>>>
>>> No milestones specified
>>>
>>>
>>> Anticipated spec changes
>>>
>>> Open questions about a feature may be a source of future web compat or 
>>> interop issues. Please list open issues (e.g. links to known github issues 
>>> in the project for the feature specification) whose resolution may 
>>> introduce web compat/interop risk (e.g., changing to naming or structure of 
>>> the API in a non-backward-compatible way).
>>> None Expected
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://chromestatus.com/feature/5147732899004416
>>>
>>> Links to previous Intent discussionsIntent to prototype: 
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CFBE060E-9D1C-4B8D-A4FB-B0279D73E6F4%40gmail.com
>>>
>>> This intent message was generated by Chrome Platform Status 
>>> .
>>>
>>> -- 
>>> 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.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/A73025EA-70D7-4818-9CFF-AE14B48875F0%40gmail.com
>>>  
>>> 

Re: [blink-dev] Intent to Ship: Add value argument to URLSearchParams's has() and delete()

[Andreu Botella]

jornalmassa.com.br doesn't seem to be calling these methods with two 
arguments, at least in my testing. The rest of sites do occasionally 
(sometimes with the second argument being 0, sometimes a different 
number, sometimes a string), but none seemed to break in my testing.


Andreu

On 5/12/23 10:38, Philip Jägenstedt wrote:
It looks like this was spec'd in 
https://github.com/whatwg/url/pull/735, with participation from 
Chromium and WebKit folks. 
https://bugzilla.mozilla.org/show_bug.cgi?id=1831587 was filed for 
Gecko, but there's no clear position. Would you mind filing an issue 
at https://github.com/mozilla/standards-positions/issues/new to ensure 
Mozilla is aware this happening?


https://chromestatus.com/metrics/feature/timeline/popularity/4478 is 
pretty low, but was any analysis done of sites that reach this use 
counter? It's honestly higher usage than I'd expect for an argument 
that didn't do anything before, so likely the value passed doesn't 
make sense and will result in the parameter not being deleted for 
delete(), which could be a problem. What can you say about usage in 
the wild here?


+Andreu Botella 

On Fri, May 12, 2023 at 9:30 AM Debadree Chatterjee 
 wrote:



Contact emails

debadree...@gmail.com


Explainer

None


Specification

https://url.spec.whatwg.org/#dom-urlsearchparams-has


Summary

This feature adds the ability to pass a `value` argument to
URLSearchParams's has() and delete() methods which allow for
deleting tuples stored in URLSearchParams either by the `name`
parameter or by the combination of `name` and `value`



Blink component

Blink



TAG review

None


TAG review status

Not applicable


Risks



Interoperability and Compatibility

Compatibility with existing websites were tested by means of a
Counter in chromium, ref:
https://github.com/whatwg/url/pull/735#issuecomment-1441503315 and
no significant chances of breaking were found

/Gecko/: No signal

/WebKit/: No signal

/Web developers/: Has Shipped
(https://github.com/WebKit/WebKit/pull/13500)

/Other signals/:


WebView application risks

Does this intent deprecate or change behavior of existing APIs,
such that it has potentially high risk for Android WebView-based
applications?

None expected



Debuggability

None


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

Yes


Is this feature fully tested by web-platform-tests

?

Yes


Flag name



Requires code in //chrome?

False


Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1442916


Estimated milestones

No milestones specified



Anticipated spec changes

Open questions about a feature may be a source of future web
compat or interop issues. Please list open issues (e.g. links to
known github issues in the project for the feature specification)
whose resolution may introduce web compat/interop risk (e.g.,
changing to naming or structure of the API in a
non-backward-compatible way).

None Expected


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5147732899004416


Links to previous Intent discussions

Intent to prototype:

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CFBE060E-9D1C-4B8D-A4FB-B0279D73E6F4%40gmail.com

This intent message was generated by Chrome Platform Status
.
-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/A73025EA-70D7-4818-9CFF-AE14B48875F0%40gmail.com

.



--
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/857d5cfc-4afc-93a6-2f74-76ec4c70ba68%40igalia.com.

Re: [blink-dev] Intent to Ship: Add value argument to URLSearchParams's has() and delete()

[Philip Jägenstedt]

Hey Andreu,

Can you give an example of what the code looks like that calls the methods
with a second argument?

Best regards,
Philip

On Fri, May 12, 2023 at 8:51 PM Andreu Botella  wrote:

> jornalmassa.com.br doesn't seem to be calling these methods with two
> arguments, at least in my testing. The rest of sites do occasionally
> (sometimes with the second argument being 0, sometimes a different
> number, sometimes a string), but none seemed to break in my testing.
>
> Andreu
> On 5/12/23 10:38, Philip Jägenstedt wrote:
>
> It looks like this was spec'd in https://github.com/whatwg/url/pull/735,
> with participation from Chromium and WebKit folks.
> https://bugzilla.mozilla.org/show_bug.cgi?id=1831587 was filed for Gecko,
> but there's no clear position. Would you mind filing an issue at
> https://github.com/mozilla/standards-positions/issues/new to ensure
> Mozilla is aware this happening?
>
> https://chromestatus.com/metrics/feature/timeline/popularity/4478 is
> pretty low, but was any analysis done of sites that reach this use counter?
> It's honestly higher usage than I'd expect for an argument that didn't do
> anything before, so likely the value passed doesn't make sense and will
> result in the parameter not being deleted for delete(), which could be a
> problem. What can you say about usage in the wild here?
>
> +Andreu Botella 
>
> On Fri, May 12, 2023 at 9:30 AM Debadree Chatterjee 
> wrote:
>
>> Contact emails debadree...@gmail.com
>>
>> Explainer None
>>
>> Specification https://url.spec.whatwg.org/#dom-urlsearchparams-has
>>
>> Summary
>>
>> This feature adds the ability to pass a `value` argument to
>> URLSearchParams's has() and delete() methods which allow for deleting
>> tuples stored in URLSearchParams either by the `name` parameter or by the
>> combination of `name` and `value`
>>
>>
>> Blink component Blink
>> 
>>
>> TAG review None
>>
>> TAG review status Not applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility Compatibility with existing websites
>> were tested by means of a Counter in chromium, ref:
>> https://github.com/whatwg/url/pull/735#issuecomment-1441503315 and no
>> significant chances of breaking were found
>>
>> *Gecko*: No signal
>>
>> *WebKit*: No signal
>>
>> *Web developers*: Has Shipped (
>> https://github.com/WebKit/WebKit/pull/13500)
>>
>> *Other signals*:
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>> None expected
>>
>>
>> Debuggability None
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?
>> Yes
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>> Yes
>>
>> Flag name
>>
>> Requires code in //chrome? False
>>
>> Tracking bug
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1442916
>>
>> Estimated milestones
>>
>> No milestones specified
>>
>>
>> Anticipated spec changes
>>
>> Open questions about a feature may be a source of future web compat or
>> interop issues. Please list open issues (e.g. links to known github issues
>> in the project for the feature specification) whose resolution may
>> introduce web compat/interop risk (e.g., changing to naming or structure of
>> the API in a non-backward-compatible way).
>> None Expected
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5147732899004416
>>
>> Links to previous Intent discussions Intent to prototype:
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CFBE060E-9D1C-4B8D-A4FB-B0279D73E6F4%40gmail.com
>>
>> This intent message was generated by Chrome Platform Status
>> .
>> --
>> 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+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/A73025EA-70D7-4818-9CFF-AE14B48875F0%40gmail.com
>> 
>> .
>>
>

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYcgT4HVYsB3tsDEpA%2B4-niBhZv5Op-ztxCi-Ae9mdAzdQ%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Add value argument to URLSearchParams's has() and delete()

[Debadree Chatterjee]

Hey!

update from mozilla's side they seem to be positive: 
https://github.com/mozilla/standards-positions/issues/801#issuecomment-1547693061

On Monday, May 15, 2023 at 2:55:45 PM UTC+5:30 Philip Jägenstedt wrote:

> Hey Andreu,
>
> Can you give an example of what the code looks like that calls the methods 
> with a second argument?
>
> Best regards,
> Philip
>
> On Fri, May 12, 2023 at 8:51 PM Andreu Botella  wrote:
>
>> jornalmassa.com.br doesn't seem to be calling these methods with two 
>> arguments, at least in my testing. The rest of sites do occasionally 
>> (sometimes with the second argument being 0, sometimes a different 
>> number, sometimes a string), but none seemed to break in my testing.
>>
>> Andreu
>> On 5/12/23 10:38, Philip Jägenstedt wrote:
>>
>> It looks like this was spec'd in https://github.com/whatwg/url/pull/735, 
>> with participation from Chromium and WebKit folks. 
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1831587 was filed for 
>> Gecko, but there's no clear position. Would you mind filing an issue at 
>> https://github.com/mozilla/standards-positions/issues/new to ensure 
>> Mozilla is aware this happening? 
>>
>> https://chromestatus.com/metrics/feature/timeline/popularity/4478 is 
>> pretty low, but was any analysis done of sites that reach this use counter? 
>> It's honestly higher usage than I'd expect for an argument that didn't do 
>> anything before, so likely the value passed doesn't make sense and will 
>> result in the parameter not being deleted for delete(), which could be a 
>> problem. What can you say about usage in the wild here?
>>
>> +Andreu Botella 
>>
>> On Fri, May 12, 2023 at 9:30 AM Debadree Chatterjee  
>> wrote:
>>
>>> Contact emails debad...@gmail.com
>>>
>>> Explainer None
>>>
>>> Specification https://url.spec.whatwg.org/#dom-urlsearchparams-has
>>>
>>> Summary 
>>>
>>> This feature adds the ability to pass a `value` argument to 
>>> URLSearchParams's has() and delete() methods which allow for deleting 
>>> tuples stored in URLSearchParams either by the `name` parameter or by the 
>>> combination of `name` and `value`
>>>
>>>
>>> Blink component Blink 
>>> 
>>>
>>> TAG review None
>>>
>>> TAG review status Not applicable
>>>
>>> Risks 
>>>
>>>
>>> Interoperability and Compatibility Compatibility with existing websites 
>>> were tested by means of a Counter in chromium, ref: 
>>> https://github.com/whatwg/url/pull/735#issuecomment-1441503315 and no 
>>> significant chances of breaking were found
>>>
>>> *Gecko*: No signal
>>>
>>> *WebKit*: No signal
>>>
>>> *Web developers*: Has Shipped (
>>> https://github.com/WebKit/WebKit/pull/13500)
>>>
>>> *Other signals*:
>>>
>>> WebView application risks 
>>>
>>> Does this intent deprecate or change behavior of existing APIs, such 
>>> that it has potentially high risk for Android WebView-based applications?
>>>
>>> None expected
>>>
>>>
>>> Debuggability None
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac, 
>>> Linux, Chrome OS, Android, and Android WebView)? 
>>> Yes
>>>
>>> Is this feature fully tested by web-platform-tests 
>>> 
>>> ? 
>>> Yes
>>>
>>> Flag name 
>>>
>>> Requires code in //chrome? False
>>>
>>> Tracking bug 
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1442916
>>>
>>> Estimated milestones 
>>>
>>> No milestones specified
>>>
>>>
>>> Anticipated spec changes 
>>>
>>> Open questions about a feature may be a source of future web compat or 
>>> interop issues. Please list open issues (e.g. links to known github issues 
>>> in the project for the feature specification) whose resolution may 
>>> introduce web compat/interop risk (e.g., changing to naming or structure of 
>>> the API in a non-backward-compatible way).
>>> None Expected
>>>
>>> Link to entry on the Chrome Platform Status 
>>> https://chromestatus.com/feature/5147732899004416
>>>
>>> Links to previous Intent discussions Intent to prototype: 
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CFBE060E-9D1C-4B8D-A4FB-B0279D73E6F4%40gmail.com
>>>
>>> This intent message was generated by Chrome Platform Status 
>>> .
>>> -- 
>>> 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.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/A73025EA-70D7-4818-9CFF-AE14B48875F0%40gmail.com
>>>  
>>> 
>>> .
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group a

Re: [blink-dev] Intent to Ship: Add value argument to URLSearchParams's has() and delete()

[PhistucK]

It would be something like this -
https://groups.google.com/a/chromium.org/g/blink-dev/c/rDaQdKpWAx8/m/qjTlRNShAgAJ

☆*PhistucK*


On Mon, May 15, 2023 at 10:25 AM Philip Jägenstedt 
wrote:

> Hey Andreu,
>
> Can you give an example of what the code looks like that calls the methods
> with a second argument?
>
> Best regards,
> Philip
>
> On Fri, May 12, 2023 at 8:51 PM Andreu Botella 
> wrote:
>
>> jornalmassa.com.br doesn't seem to be calling these methods with two
>> arguments, at least in my testing. The rest of sites do occasionally
>> (sometimes with the second argument being 0, sometimes a different
>> number, sometimes a string), but none seemed to break in my testing.
>>
>> Andreu
>> On 5/12/23 10:38, Philip Jägenstedt wrote:
>>
>> It looks like this was spec'd in https://github.com/whatwg/url/pull/735,
>> with participation from Chromium and WebKit folks.
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1831587 was filed for
>> Gecko, but there's no clear position. Would you mind filing an issue at
>> https://github.com/mozilla/standards-positions/issues/new to ensure
>> Mozilla is aware this happening?
>>
>> https://chromestatus.com/metrics/feature/timeline/popularity/4478 is
>> pretty low, but was any analysis done of sites that reach this use counter?
>> It's honestly higher usage than I'd expect for an argument that didn't do
>> anything before, so likely the value passed doesn't make sense and will
>> result in the parameter not being deleted for delete(), which could be a
>> problem. What can you say about usage in the wild here?
>>
>> +Andreu Botella 
>>
>> On Fri, May 12, 2023 at 9:30 AM Debadree Chatterjee <
>> debadree...@gmail.com> wrote:
>>
>>> Contact emails debadree...@gmail.com
>>>
>>> Explainer None
>>>
>>> Specification https://url.spec.whatwg.org/#dom-urlsearchparams-has
>>>
>>> Summary
>>>
>>> This feature adds the ability to pass a `value` argument to
>>> URLSearchParams's has() and delete() methods which allow for deleting
>>> tuples stored in URLSearchParams either by the `name` parameter or by the
>>> combination of `name` and `value`
>>>
>>>
>>> Blink component Blink
>>> 
>>>
>>> TAG review None
>>>
>>> TAG review status Not applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility Compatibility with existing websites
>>> were tested by means of a Counter in chromium, ref:
>>> https://github.com/whatwg/url/pull/735#issuecomment-1441503315 and no
>>> significant chances of breaking were found
>>>
>>> *Gecko*: No signal
>>>
>>> *WebKit*: No signal
>>>
>>> *Web developers*: Has Shipped (
>>> https://github.com/WebKit/WebKit/pull/13500)
>>>
>>> *Other signals*:
>>>
>>> WebView application risks
>>>
>>> Does this intent deprecate or change behavior of existing APIs, such
>>> that it has potentially high risk for Android WebView-based applications?
>>>
>>> None expected
>>>
>>>
>>> Debuggability None
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, Chrome OS, Android, and Android WebView)?
>>> Yes
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?
>>> Yes
>>>
>>> Flag name
>>>
>>> Requires code in //chrome? False
>>>
>>> Tracking bug
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1442916
>>>
>>> Estimated milestones
>>>
>>> No milestones specified
>>>
>>>
>>> Anticipated spec changes
>>>
>>> Open questions about a feature may be a source of future web compat or
>>> interop issues. Please list open issues (e.g. links to known github issues
>>> in the project for the feature specification) whose resolution may
>>> introduce web compat/interop risk (e.g., changing to naming or structure of
>>> the API in a non-backward-compatible way).
>>> None Expected
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://chromestatus.com/feature/5147732899004416
>>>
>>> Links to previous Intent discussions Intent to prototype:
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CFBE060E-9D1C-4B8D-A4FB-B0279D73E6F4%40gmail.com
>>>
>>> This intent message was generated by Chrome Platform Status
>>> .
>>> --
>>> 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+unsubscr...@chromium.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/A73025EA-70D7-4818-9CFF-AE14B48875F0%40gmail.com
>>> 
>>> .
>>>
>> --
> 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, sen

Re: [blink-dev] Intent to Ship: Add value argument to URLSearchParams's has() and delete()

[Debadree Chatterjee]

Hey Everyone!

I am writing to seek some help regarding identifying code patterns as you 
say, almost all the code in these sites seems to be minified compacted so 
quite difficult to find manually does anyone know a better way to go about 
it? like is there an example of maybe modifying some code in Chrome to 
detect these code patterns? 

Yours Sincerely,
Debadree
On Monday, May 15, 2023 at 10:06:05 PM UTC+5:30 PhistucK wrote:

> It would be something like this -
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/rDaQdKpWAx8/m/qjTlRNShAgAJ
>
> ☆*PhistucK*
>
>
> On Mon, May 15, 2023 at 10:25 AM Philip Jägenstedt  
> wrote:
>
>> Hey Andreu,
>>
>> Can you give an example of what the code looks like that calls the 
>> methods with a second argument?
>>
>> Best regards,
>> Philip
>>
>> On Fri, May 12, 2023 at 8:51 PM Andreu Botella  
>> wrote:
>>
>>> jornalmassa.com.br doesn't seem to be calling these methods with two 
>>> arguments, at least in my testing. The rest of sites do occasionally 
>>> (sometimes with the second argument being 0, sometimes a different 
>>> number, sometimes a string), but none seemed to break in my testing.
>>>
>>> Andreu
>>> On 5/12/23 10:38, Philip Jägenstedt wrote:
>>>
>>> It looks like this was spec'd in https://github.com/whatwg/url/pull/735, 
>>> with participation from Chromium and WebKit folks. 
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1831587 was filed for 
>>> Gecko, but there's no clear position. Would you mind filing an issue at 
>>> https://github.com/mozilla/standards-positions/issues/new to ensure 
>>> Mozilla is aware this happening? 
>>>
>>> https://chromestatus.com/metrics/feature/timeline/popularity/4478 is 
>>> pretty low, but was any analysis done of sites that reach this use counter? 
>>> It's honestly higher usage than I'd expect for an argument that didn't do 
>>> anything before, so likely the value passed doesn't make sense and will 
>>> result in the parameter not being deleted for delete(), which could be a 
>>> problem. What can you say about usage in the wild here?
>>>
>>> +Andreu Botella 
>>>
>>> On Fri, May 12, 2023 at 9:30 AM Debadree Chatterjee  
>>> wrote:
>>>
 Contact emails debad...@gmail.com

 Explainer None

 Specification https://url.spec.whatwg.org/#dom-urlsearchparams-has

 Summary 

 This feature adds the ability to pass a `value` argument to 
 URLSearchParams's has() and delete() methods which allow for deleting 
 tuples stored in URLSearchParams either by the `name` parameter or by the 
 combination of `name` and `value`


 Blink component Blink 
 

 TAG review None

 TAG review status Not applicable

 Risks 


 Interoperability and Compatibility Compatibility with existing 
 websites were tested by means of a Counter in chromium, ref: 
 https://github.com/whatwg/url/pull/735#issuecomment-1441503315 and no 
 significant chances of breaking were found

 *Gecko*: No signal

 *WebKit*: No signal

 *Web developers*: Has Shipped (
 https://github.com/WebKit/WebKit/pull/13500)

 *Other signals*:

 WebView application risks 

 Does this intent deprecate or change behavior of existing APIs, such 
 that it has potentially high risk for Android WebView-based applications?

 None expected


 Debuggability None

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

 Is this feature fully tested by web-platform-tests 
 
 ? 
 Yes

 Flag name 

 Requires code in //chrome? False

 Tracking bug 
 https://bugs.chromium.org/p/chromium/issues/detail?id=1442916

 Estimated milestones 

 No milestones specified


 Anticipated spec changes 

 Open questions about a feature may be a source of future web compat or 
 interop issues. Please list open issues (e.g. links to known github issues 
 in the project for the feature specification) whose resolution may 
 introduce web compat/interop risk (e.g., changing to naming or structure 
 of 
 the API in a non-backward-compatible way).
 None Expected

 Link to entry on the Chrome Platform Status 
 https://chromestatus.com/feature/5147732899004416

 Links to previous Intent discussions Intent to prototype: 
 https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CFBE060E-9D1C-4B8D-A4FB-B0279D73E6F4%40gmail.com

 This intent message was generated by Chrome Platform Status 
 .
 -- 
 You received this message because you are subscribed to the Google 
 Groups "blink-dev" group.
 To unsubsc

Re: [blink-dev] Intent to Ship: Add value argument to URLSearchParams's has() and delete()

[Philip Jägenstedt]

Hi Debadree, minified code is OK, all we need to see is what the call site
looks like. In particular is it an explicit and intentional extra arg like
`someUrl.searchParams.delete('something', extraArg)`, or is it a callback
involving forEach or similar?

With some way to break in devtools at the code path in question, it
should be a question of stepping up the call stack one level. The most
straightforward way to do this would be a local change to Chromium, to make
the methods throw an exception if given and extra argument, and then
looking for the exception in devtools.

Does that sound workable? If it's unreasonably hard to do, then we need
some other way to understand what the usage in the wild is about.

On Wed, May 17, 2023 at 5:27 PM Debadree Chatterjee 
wrote:

> Hey Everyone!
>
> I am writing to seek some help regarding identifying code patterns as you
> say, almost all the code in these sites seems to be minified compacted so
> quite difficult to find manually does anyone know a better way to go about
> it? like is there an example of maybe modifying some code in Chrome to
> detect these code patterns?
>
> Yours Sincerely,
> Debadree
> On Monday, May 15, 2023 at 10:06:05 PM UTC+5:30 PhistucK wrote:
>
>> It would be something like this -
>>
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/rDaQdKpWAx8/m/qjTlRNShAgAJ
>>
>> ☆*PhistucK*
>>
>>
>> On Mon, May 15, 2023 at 10:25 AM Philip Jägenstedt 
>> wrote:
>>
>>> Hey Andreu,
>>>
>>> Can you give an example of what the code looks like that calls the
>>> methods with a second argument?
>>>
>>> Best regards,
>>> Philip
>>>
>>> On Fri, May 12, 2023 at 8:51 PM Andreu Botella 
>>> wrote:
>>>
 jornalmassa.com.br doesn't seem to be calling these methods with two
 arguments, at least in my testing. The rest of sites do occasionally
 (sometimes with the second argument being 0, sometimes a different
 number, sometimes a string), but none seemed to break in my testing.

 Andreu
 On 5/12/23 10:38, Philip Jägenstedt wrote:

 It looks like this was spec'd in https://github.com/whatwg/url/pull/735,
 with participation from Chromium and WebKit folks.
 https://bugzilla.mozilla.org/show_bug.cgi?id=1831587 was filed for
 Gecko, but there's no clear position. Would you mind filing an issue at
 https://github.com/mozilla/standards-positions/issues/new to ensure
 Mozilla is aware this happening?

 https://chromestatus.com/metrics/feature/timeline/popularity/4478 is
 pretty low, but was any analysis done of sites that reach this use counter?
 It's honestly higher usage than I'd expect for an argument that didn't do
 anything before, so likely the value passed doesn't make sense and will
 result in the parameter not being deleted for delete(), which could be a
 problem. What can you say about usage in the wild here?

 +Andreu Botella

 On Fri, May 12, 2023 at 9:30 AM Debadree Chatterjee 
 wrote:

> Contact emails debad...@gmail.com
>
> Explainer None
>
> Specification https://url.spec.whatwg.org/#dom-urlsearchparams-has
>
> Summary
>
> This feature adds the ability to pass a `value` argument to
> URLSearchParams's has() and delete() methods which allow for deleting
> tuples stored in URLSearchParams either by the `name` parameter or by the
> combination of `name` and `value`
>
>
> Blink component Blink
> 
>
> TAG review None
>
> TAG review status Not applicable
>
> Risks
>
>
> Interoperability and Compatibility Compatibility with existing
> websites were tested by means of a Counter in chromium, ref:
> https://github.com/whatwg/url/pull/735#issuecomment-1441503315 and no
> significant chances of breaking were found
>
> *Gecko*: No signal
>
> *WebKit*: No signal
>
> *Web developers*: Has Shipped (
> https://github.com/WebKit/WebKit/pull/13500)
>
> *Other signals*:
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such
> that it has potentially high risk for Android WebView-based applications?
>
> None expected
>
>
> Debuggability None
>
> Will this feature be supported on all six Blink platforms (Windows,
> Mac, Linux, Chrome OS, Android, and Android WebView)?
> Yes
>
> Is this feature fully tested by web-platform-tests
> 
> ?
> Yes
>
> Flag name
>
> Requires code in //chrome? False
>
> Tracking bug
> https://bugs.chromium.org/p/chromium/issues/detail?id=1442916
>
> Estimated milestones
>
> No milestones specified
>
>
> Anticipated spec changes
>
> Open questions about a featur

Re: [blink-dev] Intent to Ship: Add value argument to URLSearchParams's has() and delete()

[PhistucK]

Excessive, but you can run this in the console -
debug(URLSearchParams.prototype.has)
debug(URLSearchParams.prototype.delete)
That will break whenever those are called.
If you want it to break less, you can replace the functions with your own
and run debugger; in case there is more than one parameter -
var originalHas = URLSearchParams.prototype.has;
URLSearchParams.prototype.has = (...a) => { if (a.length > 1) debugger;
return originalHas.call(this, ...a); }
var originalDelete = URLSearchParams.prototype.delete;
URLSearchParams.prototype.delete = (...a) => { if (a.length > 1) debugger;
return originalDelete.call(this, ...a); }
But make sure you run this very early on the page somehow.

☆*PhistucK*


On Wed, May 17, 2023 at 5:17 PM Philip Jägenstedt 
wrote:

> Hi Debadree, minified code is OK, all we need to see is what the call site
> looks like. In particular is it an explicit and intentional extra arg like
> `someUrl.searchParams.delete('something', extraArg)`, or is it a callback
> involving forEach or similar?
>
> With some way to break in devtools at the code path in question, it
> should be a question of stepping up the call stack one level. The most
> straightforward way to do this would be a local change to Chromium, to make
> the methods throw an exception if given and extra argument, and then
> looking for the exception in devtools.
>
> Does that sound workable? If it's unreasonably hard to do, then we need
> some other way to understand what the usage in the wild is about.
>
> On Wed, May 17, 2023 at 5:27 PM Debadree Chatterjee 
> wrote:
>
>> Hey Everyone!
>>
>> I am writing to seek some help regarding identifying code patterns as you
>> say, almost all the code in these sites seems to be minified compacted so
>> quite difficult to find manually does anyone know a better way to go about
>> it? like is there an example of maybe modifying some code in Chrome to
>> detect these code patterns?
>>
>> Yours Sincerely,
>> Debadree
>> On Monday, May 15, 2023 at 10:06:05 PM UTC+5:30 PhistucK wrote:
>>
>>> It would be something like this -
>>>
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/rDaQdKpWAx8/m/qjTlRNShAgAJ
>>>
>>> ☆*PhistucK*
>>>
>>>
>>> On Mon, May 15, 2023 at 10:25 AM Philip Jägenstedt 
>>> wrote:
>>>
 Hey Andreu,

 Can you give an example of what the code looks like that calls the
 methods with a second argument?

 Best regards,
 Philip

 On Fri, May 12, 2023 at 8:51 PM Andreu Botella 
 wrote:

> jornalmassa.com.br doesn't seem to be calling these methods with two
> arguments, at least in my testing. The rest of sites do occasionally
> (sometimes with the second argument being 0, sometimes a different
> number, sometimes a string), but none seemed to break in my testing.
>
> Andreu
> On 5/12/23 10:38, Philip Jägenstedt wrote:
>
> It looks like this was spec'd in
> https://github.com/whatwg/url/pull/735, with participation from
> Chromium and WebKit folks.
> https://bugzilla.mozilla.org/show_bug.cgi?id=1831587 was filed for
> Gecko, but there's no clear position. Would you mind filing an issue at
> https://github.com/mozilla/standards-positions/issues/new to ensure
> Mozilla is aware this happening?
>
> https://chromestatus.com/metrics/feature/timeline/popularity/4478 is
> pretty low, but was any analysis done of sites that reach this use 
> counter?
> It's honestly higher usage than I'd expect for an argument that didn't do
> anything before, so likely the value passed doesn't make sense and will
> result in the parameter not being deleted for delete(), which could be a
> problem. What can you say about usage in the wild here?
>
> +Andreu Botella
>
> On Fri, May 12, 2023 at 9:30 AM Debadree Chatterjee <
> debad...@gmail.com> wrote:
>
>> Contact emails debad...@gmail.com
>>
>> Explainer None
>>
>> Specification https://url.spec.whatwg.org/#dom-urlsearchparams-has
>>
>> Summary
>>
>> This feature adds the ability to pass a `value` argument to
>> URLSearchParams's has() and delete() methods which allow for deleting
>> tuples stored in URLSearchParams either by the `name` parameter or by the
>> combination of `name` and `value`
>>
>>
>> Blink component Blink
>> 
>>
>> TAG review None
>>
>> TAG review status Not applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility Compatibility with existing
>> websites were tested by means of a Counter in chromium, ref:
>> https://github.com/whatwg/url/pull/735#issuecomment-1441503315 and
>> no significant chances of breaking were found
>>
>> *Gecko*: No signal
>>
>> *WebKit*: No signal
>>
>> *Web developers*: Has Shipped (
>> https://github.com/WebKit/WebKit/pull/13500)

Re: [blink-dev] Intent to Ship: Add value argument to URLSearchParams's has() and delete()

[Philip Jägenstedt]

Thanks PhistucK, I didn't know about these devtools tricks :D

On Wed, May 17, 2023 at 6:31 PM PhistucK  wrote:

> Excessive, but you can run this in the console -
> debug(URLSearchParams.prototype.has)
> debug(URLSearchParams.prototype.delete)
> That will break whenever those are called.
> If you want it to break less, you can replace the functions with your own
> and run debugger; in case there is more than one parameter -
> var originalHas = URLSearchParams.prototype.has;
> URLSearchParams.prototype.has = (...a) => { if (a.length > 1) debugger;
> return originalHas.call(this, ...a); }
> var originalDelete = URLSearchParams.prototype.delete;
> URLSearchParams.prototype.delete = (...a) => { if (a.length > 1) debugger;
> return originalDelete.call(this, ...a); }
> But make sure you run this very early on the page somehow.
>
> ☆*PhistucK*
>
>
> On Wed, May 17, 2023 at 5:17 PM Philip Jägenstedt 
> wrote:
>
>> Hi Debadree, minified code is OK, all we need to see is what the call
>> site looks like. In particular is it an explicit and intentional extra arg
>> like `someUrl.searchParams.delete('something', extraArg)`, or is it a
>> callback involving forEach or similar?
>>
>> With some way to break in devtools at the code path in question, it
>> should be a question of stepping up the call stack one level. The most
>> straightforward way to do this would be a local change to Chromium, to make
>> the methods throw an exception if given and extra argument, and then
>> looking for the exception in devtools.
>>
>> Does that sound workable? If it's unreasonably hard to do, then we need
>> some other way to understand what the usage in the wild is about.
>>
>> On Wed, May 17, 2023 at 5:27 PM Debadree Chatterjee <
>> debadree...@gmail.com> wrote:
>>
>>> Hey Everyone!
>>>
>>> I am writing to seek some help regarding identifying code patterns as
>>> you say, almost all the code in these sites seems to be minified compacted
>>> so quite difficult to find manually does anyone know a better way to go
>>> about it? like is there an example of maybe modifying some code in Chrome
>>> to detect these code patterns?
>>>
>>> Yours Sincerely,
>>> Debadree
>>> On Monday, May 15, 2023 at 10:06:05 PM UTC+5:30 PhistucK wrote:
>>>
 It would be something like this -

 https://groups.google.com/a/chromium.org/g/blink-dev/c/rDaQdKpWAx8/m/qjTlRNShAgAJ

 ☆*PhistucK*


 On Mon, May 15, 2023 at 10:25 AM Philip Jägenstedt 
 wrote:

> Hey Andreu,
>
> Can you give an example of what the code looks like that calls the
> methods with a second argument?
>
> Best regards,
> Philip
>
> On Fri, May 12, 2023 at 8:51 PM Andreu Botella 
> wrote:
>
>> jornalmassa.com.br doesn't seem to be calling these methods with two
>> arguments, at least in my testing. The rest of sites do occasionally
>> (sometimes with the second argument being 0, sometimes a different
>> number, sometimes a string), but none seemed to break in my testing.
>>
>> Andreu
>> On 5/12/23 10:38, Philip Jägenstedt wrote:
>>
>> It looks like this was spec'd in
>> https://github.com/whatwg/url/pull/735, with participation from
>> Chromium and WebKit folks.
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1831587 was filed for
>> Gecko, but there's no clear position. Would you mind filing an issue at
>> https://github.com/mozilla/standards-positions/issues/new to ensure
>> Mozilla is aware this happening?
>>
>> https://chromestatus.com/metrics/feature/timeline/popularity/4478 is
>> pretty low, but was any analysis done of sites that reach this use 
>> counter?
>> It's honestly higher usage than I'd expect for an argument that didn't do
>> anything before, so likely the value passed doesn't make sense and will
>> result in the parameter not being deleted for delete(), which could be a
>> problem. What can you say about usage in the wild here?
>>
>> +Andreu Botella
>>
>> On Fri, May 12, 2023 at 9:30 AM Debadree Chatterjee <
>> debad...@gmail.com> wrote:
>>
>>> Contact emails debad...@gmail.com
>>>
>>> Explainer None
>>>
>>> Specification https://url.spec.whatwg.org/#dom-urlsearchparams-has
>>>
>>> Summary
>>>
>>> This feature adds the ability to pass a `value` argument to
>>> URLSearchParams's has() and delete() methods which allow for deleting
>>> tuples stored in URLSearchParams either by the `name` parameter or by 
>>> the
>>> combination of `name` and `value`
>>>
>>>
>>> Blink component Blink
>>> 
>>>
>>> TAG review None
>>>
>>> TAG review status Not applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility Compatibility with existing
>>> websites were tested by means of a Counter in chromium, ref:
>>> h

Re: [blink-dev] Intent to Ship: Add value argument to URLSearchParams's has() and delete()

[Debadree Chatterjee]

Hey!

Phistuck's method sounds interesting! I am giving it a try and reporting 
back! Thank you so much, everyone!

On Wednesday, May 17, 2023 at 10:09:10 PM UTC+5:30 Philip Jägenstedt wrote:

> Thanks PhistucK, I didn't know about these devtools tricks :D
>
> On Wed, May 17, 2023 at 6:31 PM PhistucK  wrote:
>
>> Excessive, but you can run this in the console -
>> debug(URLSearchParams.prototype.has)
>> debug(URLSearchParams.prototype.delete)
>> That will break whenever those are called.
>> If you want it to break less, you can replace the functions with your own 
>> and run debugger; in case there is more than one parameter -
>> var originalHas = URLSearchParams.prototype.has;
>> URLSearchParams.prototype.has = (...a) => { if (a.length > 1) debugger; 
>> return originalHas.call(this, ...a); }
>> var originalDelete = URLSearchParams.prototype.delete;
>> URLSearchParams.prototype.delete = (...a) => { if (a.length > 1) 
>> debugger; return originalDelete.call(this, ...a); }
>> But make sure you run this very early on the page somehow.
>>
>> ☆*PhistucK*
>>
>>
>> On Wed, May 17, 2023 at 5:17 PM Philip Jägenstedt  
>> wrote:
>>
>>> Hi Debadree, minified code is OK, all we need to see is what the call 
>>> site looks like. In particular is it an explicit and intentional extra arg 
>>> like `someUrl.searchParams.delete('something', extraArg)`, or is it a 
>>> callback involving forEach or similar?
>>>
>>> With some way to break in devtools at the code path in question, it 
>>> should be a question of stepping up the call stack one level. The most 
>>> straightforward way to do this would be a local change to Chromium, to make 
>>> the methods throw an exception if given and extra argument, and then 
>>> looking for the exception in devtools.
>>>
>>> Does that sound workable? If it's unreasonably hard to do, then we need 
>>> some other way to understand what the usage in the wild is about.
>>>
>>> On Wed, May 17, 2023 at 5:27 PM Debadree Chatterjee  
>>> wrote:
>>>
 Hey Everyone!

 I am writing to seek some help regarding identifying code patterns as 
 you say, almost all the code in these sites seems to be minified compacted 
 so quite difficult to find manually does anyone know a better way to go 
 about it? like is there an example of maybe modifying some code in Chrome 
 to detect these code patterns? 

 Yours Sincerely,
 Debadree
 On Monday, May 15, 2023 at 10:06:05 PM UTC+5:30 PhistucK wrote:

> It would be something like this -
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/rDaQdKpWAx8/m/qjTlRNShAgAJ
>
> ☆*PhistucK*
>
>
> On Mon, May 15, 2023 at 10:25 AM Philip Jägenstedt <
> foo...@chromium.org> wrote:
>
>> Hey Andreu,
>>
>> Can you give an example of what the code looks like that calls the 
>> methods with a second argument?
>>
>> Best regards,
>> Philip
>>
>> On Fri, May 12, 2023 at 8:51 PM Andreu Botella  
>> wrote:
>>
>>> jornalmassa.com.br doesn't seem to be calling these methods with 
>>> two arguments, at least in my testing. The rest of sites do 
>>> occasionally 
>>> (sometimes with the second argument being 0, sometimes a different 
>>> number, sometimes a string), but none seemed to break in my testing.
>>>
>>> Andreu
>>> On 5/12/23 10:38, Philip Jägenstedt wrote:
>>>
>>> It looks like this was spec'd in 
>>> https://github.com/whatwg/url/pull/735, with participation from 
>>> Chromium and WebKit folks. 
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1831587 was filed for 
>>> Gecko, but there's no clear position. Would you mind filing an issue at 
>>> https://github.com/mozilla/standards-positions/issues/new to ensure 
>>> Mozilla is aware this happening? 
>>>
>>> https://chromestatus.com/metrics/feature/timeline/popularity/4478 
>>> is pretty low, but was any analysis done of sites that reach this use 
>>> counter? It's honestly higher usage than I'd expect for an argument 
>>> that 
>>> didn't do anything before, so likely the value passed doesn't make 
>>> sense 
>>> and will result in the parameter not being deleted for delete(), which 
>>> could be a problem. What can you say about usage in the wild here?
>>>
>>> +Andreu Botella 
>>>
>>> On Fri, May 12, 2023 at 9:30 AM Debadree Chatterjee <
>>> debad...@gmail.com> wrote:
>>>
 Contact emails debad...@gmail.com

 Explainer None

 Specification https://url.spec.whatwg.org/#dom-urlsearchparams-has

 Summary 

 This feature adds the ability to pass a `value` argument to 
 URLSearchParams's has() and delete() methods which allow for deleting 
 tuples stored in URLSearchParams either by the `name` parameter or by 
 the 
 combination of `name` and `value`


>>

Re: [blink-dev] Intent to Ship: Add value argument to URLSearchParams's has() and delete()

[PhistucK]

Yes, debug(nativeFunction) is invaluable when you want to understand what
causes a JavaScript-induced navigation. :)
(Unfortunately, understanding that a simple link caused the navigation is
harder)

☆*PhistucK*


On Wed, May 17, 2023 at 5:39 PM Philip Jägenstedt 
wrote:

> Thanks PhistucK, I didn't know about these devtools tricks :D
>
> On Wed, May 17, 2023 at 6:31 PM PhistucK  wrote:
>
>> Excessive, but you can run this in the console -
>> debug(URLSearchParams.prototype.has)
>> debug(URLSearchParams.prototype.delete)
>> That will break whenever those are called.
>> If you want it to break less, you can replace the functions with your own
>> and run debugger; in case there is more than one parameter -
>> var originalHas = URLSearchParams.prototype.has;
>> URLSearchParams.prototype.has = (...a) => { if (a.length > 1) debugger;
>> return originalHas.call(this, ...a); }
>> var originalDelete = URLSearchParams.prototype.delete;
>> URLSearchParams.prototype.delete = (...a) => { if (a.length > 1)
>> debugger; return originalDelete.call(this, ...a); }
>> But make sure you run this very early on the page somehow.
>>
>> ☆*PhistucK*
>>
>>
>> On Wed, May 17, 2023 at 5:17 PM Philip Jägenstedt 
>> wrote:
>>
>>> Hi Debadree, minified code is OK, all we need to see is what the call
>>> site looks like. In particular is it an explicit and intentional extra arg
>>> like `someUrl.searchParams.delete('something', extraArg)`, or is it a
>>> callback involving forEach or similar?
>>>
>>> With some way to break in devtools at the code path in question, it
>>> should be a question of stepping up the call stack one level. The most
>>> straightforward way to do this would be a local change to Chromium, to make
>>> the methods throw an exception if given and extra argument, and then
>>> looking for the exception in devtools.
>>>
>>> Does that sound workable? If it's unreasonably hard to do, then we need
>>> some other way to understand what the usage in the wild is about.
>>>
>>> On Wed, May 17, 2023 at 5:27 PM Debadree Chatterjee <
>>> debadree...@gmail.com> wrote:
>>>
 Hey Everyone!

 I am writing to seek some help regarding identifying code patterns as
 you say, almost all the code in these sites seems to be minified compacted
 so quite difficult to find manually does anyone know a better way to go
 about it? like is there an example of maybe modifying some code in Chrome
 to detect these code patterns?

 Yours Sincerely,
 Debadree
 On Monday, May 15, 2023 at 10:06:05 PM UTC+5:30 PhistucK wrote:

> It would be something like this -
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/rDaQdKpWAx8/m/qjTlRNShAgAJ
>
> ☆*PhistucK*
>
>
> On Mon, May 15, 2023 at 10:25 AM Philip Jägenstedt <
> foo...@chromium.org> wrote:
>
>> Hey Andreu,
>>
>> Can you give an example of what the code looks like that calls the
>> methods with a second argument?
>>
>> Best regards,
>> Philip
>>
>> On Fri, May 12, 2023 at 8:51 PM Andreu Botella 
>> wrote:
>>
>>> jornalmassa.com.br doesn't seem to be calling these methods with
>>> two arguments, at least in my testing. The rest of sites do occasionally
>>> (sometimes with the second argument being 0, sometimes a different
>>> number, sometimes a string), but none seemed to break in my testing.
>>>
>>> Andreu
>>> On 5/12/23 10:38, Philip Jägenstedt wrote:
>>>
>>> It looks like this was spec'd in
>>> https://github.com/whatwg/url/pull/735, with participation from
>>> Chromium and WebKit folks.
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1831587 was filed for
>>> Gecko, but there's no clear position. Would you mind filing an issue at
>>> https://github.com/mozilla/standards-positions/issues/new to ensure
>>> Mozilla is aware this happening?
>>>
>>> https://chromestatus.com/metrics/feature/timeline/popularity/4478
>>> is pretty low, but was any analysis done of sites that reach this use
>>> counter? It's honestly higher usage than I'd expect for an argument that
>>> didn't do anything before, so likely the value passed doesn't make sense
>>> and will result in the parameter not being deleted for delete(), which
>>> could be a problem. What can you say about usage in the wild here?
>>>
>>> +Andreu Botella
>>>
>>> On Fri, May 12, 2023 at 9:30 AM Debadree Chatterjee <
>>> debad...@gmail.com> wrote:
>>>
 Contact emails debad...@gmail.com

 Explainer None

 Specification https://url.spec.whatwg.org/#dom-urlsearchparams-has

 Summary

 This feature adds the ability to pass a `value` argument to
 URLSearchParams's has() and delete() methods which allow for deleting
 tuples stored in URLSearchParams either by the `name` parameter or by 
 the
 combination of `name`

Re: [blink-dev] Intent to Ship: Add value argument to URLSearchParams's has() and delete()

[Debadree Chatterjee]

Is it possible to put these methods on Chrome startup? Like because loading 
the page would clear up devtools so in my local chromium if I could make 
these changes? any idea about which files would be relevant?

On Wednesday, May 17, 2023 at 10:11:51 PM UTC+5:30 Debadree Chatterjee 
wrote:

> Hey!
>
> Phistuck's method sounds interesting! I am giving it a try and reporting 
> back! Thank you so much, everyone!
>
> On Wednesday, May 17, 2023 at 10:09:10 PM UTC+5:30 Philip Jägenstedt wrote:
>
>> Thanks PhistucK, I didn't know about these devtools tricks :D
>>
>> On Wed, May 17, 2023 at 6:31 PM PhistucK  wrote:
>>
>>> Excessive, but you can run this in the console -
>>> debug(URLSearchParams.prototype.has)
>>> debug(URLSearchParams.prototype.delete)
>>> That will break whenever those are called.
>>> If you want it to break less, you can replace the functions with your 
>>> own and run debugger; in case there is more than one parameter -
>>> var originalHas = URLSearchParams.prototype.has;
>>> URLSearchParams.prototype.has = (...a) => { if (a.length > 1) debugger; 
>>> return originalHas.call(this, ...a); }
>>> var originalDelete = URLSearchParams.prototype.delete;
>>> URLSearchParams.prototype.delete = (...a) => { if (a.length > 1) 
>>> debugger; return originalDelete.call(this, ...a); }
>>> But make sure you run this very early on the page somehow.
>>>
>>> ☆*PhistucK*
>>>
>>>
>>> On Wed, May 17, 2023 at 5:17 PM Philip Jägenstedt  
>>> wrote:
>>>
 Hi Debadree, minified code is OK, all we need to see is what the call 
 site looks like. In particular is it an explicit and intentional extra arg 
 like `someUrl.searchParams.delete('something', extraArg)`, or is it a 
 callback involving forEach or similar?

 With some way to break in devtools at the code path in question, it 
 should be a question of stepping up the call stack one level. The most 
 straightforward way to do this would be a local change to Chromium, to 
 make 
 the methods throw an exception if given and extra argument, and then 
 looking for the exception in devtools.

 Does that sound workable? If it's unreasonably hard to do, then we need 
 some other way to understand what the usage in the wild is about.

 On Wed, May 17, 2023 at 5:27 PM Debadree Chatterjee  
 wrote:

> Hey Everyone!
>
> I am writing to seek some help regarding identifying code patterns as 
> you say, almost all the code in these sites seems to be minified 
> compacted 
> so quite difficult to find manually does anyone know a better way to go 
> about it? like is there an example of maybe modifying some code in Chrome 
> to detect these code patterns? 
>
> Yours Sincerely,
> Debadree
> On Monday, May 15, 2023 at 10:06:05 PM UTC+5:30 PhistucK wrote:
>
>> It would be something like this -
>>
>> https://groups.google.com/a/chromium.org/g/blink-dev/c/rDaQdKpWAx8/m/qjTlRNShAgAJ
>>
>> ☆*PhistucK*
>>
>>
>> On Mon, May 15, 2023 at 10:25 AM Philip Jägenstedt <
>> foo...@chromium.org> wrote:
>>
>>> Hey Andreu,
>>>
>>> Can you give an example of what the code looks like that calls the 
>>> methods with a second argument?
>>>
>>> Best regards,
>>> Philip
>>>
>>> On Fri, May 12, 2023 at 8:51 PM Andreu Botella  
>>> wrote:
>>>
 jornalmassa.com.br doesn't seem to be calling these methods with 
 two arguments, at least in my testing. The rest of sites do 
 occasionally 
 (sometimes with the second argument being 0, sometimes a different 
 number, sometimes a string), but none seemed to break in my testing.

 Andreu
 On 5/12/23 10:38, Philip Jägenstedt wrote:

 It looks like this was spec'd in 
 https://github.com/whatwg/url/pull/735, with participation from 
 Chromium and WebKit folks. 
 https://bugzilla.mozilla.org/show_bug.cgi?id=1831587 was filed for 
 Gecko, but there's no clear position. Would you mind filing an issue 
 at 
 https://github.com/mozilla/standards-positions/issues/new to 
 ensure Mozilla is aware this happening? 

 https://chromestatus.com/metrics/feature/timeline/popularity/4478 
 is pretty low, but was any analysis done of sites that reach this use 
 counter? It's honestly higher usage than I'd expect for an argument 
 that 
 didn't do anything before, so likely the value passed doesn't make 
 sense 
 and will result in the parameter not being deleted for delete(), which 
 could be a problem. What can you say about usage in the wild here?

 +Andreu Botella 

 On Fri, May 12, 2023 at 9:30 AM Debadree Chatterjee <
 debad...@gmail.com> wrote:

> Contact emails debad...@gmail.com
>
> Explainer No

Re: [blink-dev] Intent to Ship: Add value argument to URLSearchParams's has() and delete()

[PhistucK]

If you change Chromium anyway, you can just add a log/CHECK or something in
the has/delete implementation itself, right?

☆*PhistucK*


On Wed, May 17, 2023 at 5:50 PM Debadree Chatterjee 
wrote:

> Is it possible to put these methods on Chrome startup? Like because
> loading the page would clear up devtools so in my local chromium if I could
> make these changes? any idea about which files would be relevant?
>
> On Wednesday, May 17, 2023 at 10:11:51 PM UTC+5:30 Debadree Chatterjee
> wrote:
>
>> Hey!
>>
>> Phistuck's method sounds interesting! I am giving it a try and reporting
>> back! Thank you so much, everyone!
>>
>> On Wednesday, May 17, 2023 at 10:09:10 PM UTC+5:30 Philip Jägenstedt
>> wrote:
>>
>>> Thanks PhistucK, I didn't know about these devtools tricks :D
>>>
>>> On Wed, May 17, 2023 at 6:31 PM PhistucK  wrote:
>>>
 Excessive, but you can run this in the console -
 debug(URLSearchParams.prototype.has)
 debug(URLSearchParams.prototype.delete)
 That will break whenever those are called.
 If you want it to break less, you can replace the functions with your
 own and run debugger; in case there is more than one parameter -
 var originalHas = URLSearchParams.prototype.has;
 URLSearchParams.prototype.has = (...a) => { if (a.length > 1) debugger;
 return originalHas.call(this, ...a); }
 var originalDelete = URLSearchParams.prototype.delete;
 URLSearchParams.prototype.delete = (...a) => { if (a.length > 1)
 debugger; return originalDelete.call(this, ...a); }
 But make sure you run this very early on the page somehow.

 ☆*PhistucK*


 On Wed, May 17, 2023 at 5:17 PM Philip Jägenstedt 
 wrote:

> Hi Debadree, minified code is OK, all we need to see is what the call
> site looks like. In particular is it an explicit and intentional extra arg
> like `someUrl.searchParams.delete('something', extraArg)`, or is it a
> callback involving forEach or similar?
>
> With some way to break in devtools at the code path in question, it
> should be a question of stepping up the call stack one level. The most
> straightforward way to do this would be a local change to Chromium, to 
> make
> the methods throw an exception if given and extra argument, and then
> looking for the exception in devtools.
>
> Does that sound workable? If it's unreasonably hard to do, then we
> need some other way to understand what the usage in the wild is about.
>
> On Wed, May 17, 2023 at 5:27 PM Debadree Chatterjee <
> debad...@gmail.com> wrote:
>
>> Hey Everyone!
>>
>> I am writing to seek some help regarding identifying code patterns as
>> you say, almost all the code in these sites seems to be minified 
>> compacted
>> so quite difficult to find manually does anyone know a better way to go
>> about it? like is there an example of maybe modifying some code in Chrome
>> to detect these code patterns?
>>
>> Yours Sincerely,
>> Debadree
>> On Monday, May 15, 2023 at 10:06:05 PM UTC+5:30 PhistucK wrote:
>>
>>> It would be something like this -
>>>
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/rDaQdKpWAx8/m/qjTlRNShAgAJ
>>>
>>> ☆*PhistucK*
>>>
>>>
>>> On Mon, May 15, 2023 at 10:25 AM Philip Jägenstedt <
>>> foo...@chromium.org> wrote:
>>>
 Hey Andreu,

 Can you give an example of what the code looks like that calls the
 methods with a second argument?

 Best regards,
 Philip

 On Fri, May 12, 2023 at 8:51 PM Andreu Botella 
 wrote:

> jornalmassa.com.br doesn't seem to be calling these methods with
> two arguments, at least in my testing. The rest of sites do 
> occasionally
> (sometimes with the second argument being 0, sometimes a
> different number, sometimes a string), but none seemed to break in my
> testing.
>
> Andreu
> On 5/12/23 10:38, Philip Jägenstedt wrote:
>
> It looks like this was spec'd in
> https://github.com/whatwg/url/pull/735, with participation from
> Chromium and WebKit folks.
> https://bugzilla.mozilla.org/show_bug.cgi?id=1831587 was filed
> for Gecko, but there's no clear position. Would you mind filing an 
> issue at
> https://github.com/mozilla/standards-positions/issues/new to
> ensure Mozilla is aware this happening?
>
> https://chromestatus.com/metrics/feature/timeline/popularity/4478
> is pretty low, but was any analysis done of sites that reach this use
> counter? It's honestly higher usage than I'd expect for an argument 
> that
> didn't do anything before, so likely the value passed doesn't make 
> sense
> and will result in the parameter not being deleted for delete()

Re: [blink-dev] Intent to Ship: Add value argument to URLSearchParams's has() and delete()

[Debadree Chatterjee]

I mean that we have to find out how the calling function looks like so I 
was wondering if we could run your debug solution whenever a webpage loads, 
like if I could stop the page and observe what the code looks like 
On Thursday, May 18, 2023 at 12:16:26 AM UTC+5:30 PhistucK wrote:

> If you change Chromium anyway, you can just add a log/CHECK or something 
> in the has/delete implementation itself, right?
>
> ☆*PhistucK*
>
>
> On Wed, May 17, 2023 at 5:50 PM Debadree Chatterjee  
> wrote:
>
>> Is it possible to put these methods on Chrome startup? Like because 
>> loading the page would clear up devtools so in my local chromium if I could 
>> make these changes? any idea about which files would be relevant?
>>
>> On Wednesday, May 17, 2023 at 10:11:51 PM UTC+5:30 Debadree Chatterjee 
>> wrote:
>>
>>> Hey!
>>>
>>> Phistuck's method sounds interesting! I am giving it a try and reporting 
>>> back! Thank you so much, everyone!
>>>
>>> On Wednesday, May 17, 2023 at 10:09:10 PM UTC+5:30 Philip Jägenstedt 
>>> wrote:
>>>
 Thanks PhistucK, I didn't know about these devtools tricks :D

 On Wed, May 17, 2023 at 6:31 PM PhistucK  wrote:

> Excessive, but you can run this in the console -
> debug(URLSearchParams.prototype.has)
> debug(URLSearchParams.prototype.delete)
> That will break whenever those are called.
> If you want it to break less, you can replace the functions with your 
> own and run debugger; in case there is more than one parameter -
> var originalHas = URLSearchParams.prototype.has;
> URLSearchParams.prototype.has = (...a) => { if (a.length > 1) 
> debugger; return originalHas.call(this, ...a); }
> var originalDelete = URLSearchParams.prototype.delete;
> URLSearchParams.prototype.delete = (...a) => { if (a.length > 1) 
> debugger; return originalDelete.call(this, ...a); }
> But make sure you run this very early on the page somehow.
>
> ☆*PhistucK*
>
>
> On Wed, May 17, 2023 at 5:17 PM Philip Jägenstedt  
> wrote:
>
>> Hi Debadree, minified code is OK, all we need to see is what the call 
>> site looks like. In particular is it an explicit and intentional extra 
>> arg 
>> like `someUrl.searchParams.delete('something', extraArg)`, or is it a 
>> callback involving forEach or similar?
>>
>> With some way to break in devtools at the code path in question, it 
>> should be a question of stepping up the call stack one level. The most 
>> straightforward way to do this would be a local change to Chromium, to 
>> make 
>> the methods throw an exception if given and extra argument, and then 
>> looking for the exception in devtools.
>>
>> Does that sound workable? If it's unreasonably hard to do, then we 
>> need some other way to understand what the usage in the wild is about.
>>
>> On Wed, May 17, 2023 at 5:27 PM Debadree Chatterjee <
>> debad...@gmail.com> wrote:
>>
>>> Hey Everyone!
>>>
>>> I am writing to seek some help regarding identifying code patterns 
>>> as you say, almost all the code in these sites seems to be minified 
>>> compacted so quite difficult to find manually does anyone know a better 
>>> way 
>>> to go about it? like is there an example of maybe modifying some code 
>>> in 
>>> Chrome to detect these code patterns? 
>>>
>>> Yours Sincerely,
>>> Debadree
>>> On Monday, May 15, 2023 at 10:06:05 PM UTC+5:30 PhistucK wrote:
>>>
 It would be something like this -

 https://groups.google.com/a/chromium.org/g/blink-dev/c/rDaQdKpWAx8/m/qjTlRNShAgAJ

 ☆*PhistucK*


 On Mon, May 15, 2023 at 10:25 AM Philip Jägenstedt <
 foo...@chromium.org> wrote:

> Hey Andreu,
>
> Can you give an example of what the code looks like that calls the 
> methods with a second argument?
>
> Best regards,
> Philip
>
> On Fri, May 12, 2023 at 8:51 PM Andreu Botella  
> wrote:
>
>> jornalmassa.com.br doesn't seem to be calling these methods with 
>> two arguments, at least in my testing. The rest of sites do 
>> occasionally 
>> (sometimes with the second argument being 0, sometimes a 
>> different number, sometimes a string), but none seemed to break in 
>> my 
>> testing.
>>
>> Andreu
>> On 5/12/23 10:38, Philip Jägenstedt wrote:
>>
>> It looks like this was spec'd in 
>> https://github.com/whatwg/url/pull/735, with participation from 
>> Chromium and WebKit folks. 
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1831587 was filed 
>> for Gecko, but there's no clear position. Would you mind filing an 
>> issue at 
>> https://github.com/mozilla/standards-positions/issues/new to 
>>>

Re: [blink-dev] Intent to Ship: Add value argument to URLSearchParams's has() and delete()

[PhistucK]

If you emit a deprecation warning, I think it might show you the stack
trace. How to inject stuff on page load - that is beyond my knowledge. :)

☆*PhistucK*


On Wed, May 17, 2023 at 7:50 PM Debadree Chatterjee 
wrote:

>
> I mean that we have to find out how the calling function looks like so I
> was wondering if we could run your debug solution whenever a webpage loads,
> like if I could stop the page and observe what the code looks like
> On Thursday, May 18, 2023 at 12:16:26 AM UTC+5:30 PhistucK wrote:
>
>> If you change Chromium anyway, you can just add a log/CHECK or something
>> in the has/delete implementation itself, right?
>>
>> ☆*PhistucK*
>>
>>
>> On Wed, May 17, 2023 at 5:50 PM Debadree Chatterjee 
>> wrote:
>>
>>> Is it possible to put these methods on Chrome startup? Like because
>>> loading the page would clear up devtools so in my local chromium if I could
>>> make these changes? any idea about which files would be relevant?
>>>
>>> On Wednesday, May 17, 2023 at 10:11:51 PM UTC+5:30 Debadree Chatterjee
>>> wrote:
>>>
 Hey!

 Phistuck's method sounds interesting! I am giving it a try and
 reporting back! Thank you so much, everyone!

 On Wednesday, May 17, 2023 at 10:09:10 PM UTC+5:30 Philip Jägenstedt
 wrote:

> Thanks PhistucK, I didn't know about these devtools tricks :D
>
> On Wed, May 17, 2023 at 6:31 PM PhistucK  wrote:
>
>> Excessive, but you can run this in the console -
>> debug(URLSearchParams.prototype.has)
>> debug(URLSearchParams.prototype.delete)
>> That will break whenever those are called.
>> If you want it to break less, you can replace the functions with your
>> own and run debugger; in case there is more than one parameter -
>> var originalHas = URLSearchParams.prototype.has;
>> URLSearchParams.prototype.has = (...a) => { if (a.length > 1)
>> debugger; return originalHas.call(this, ...a); }
>> var originalDelete = URLSearchParams.prototype.delete;
>> URLSearchParams.prototype.delete = (...a) => { if (a.length > 1)
>> debugger; return originalDelete.call(this, ...a); }
>> But make sure you run this very early on the page somehow.
>>
>> ☆*PhistucK*
>>
>>
>> On Wed, May 17, 2023 at 5:17 PM Philip Jägenstedt <
>> foo...@chromium.org> wrote:
>>
>>> Hi Debadree, minified code is OK, all we need to see is what the
>>> call site looks like. In particular is it an explicit and intentional 
>>> extra
>>> arg like `someUrl.searchParams.delete('something', extraArg)`, or is it 
>>> a
>>> callback involving forEach or similar?
>>>
>>> With some way to break in devtools at the code path in question, it
>>> should be a question of stepping up the call stack one level. The most
>>> straightforward way to do this would be a local change to Chromium, to 
>>> make
>>> the methods throw an exception if given and extra argument, and then
>>> looking for the exception in devtools.
>>>
>>> Does that sound workable? If it's unreasonably hard to do, then we
>>> need some other way to understand what the usage in the wild is about.
>>>
>>> On Wed, May 17, 2023 at 5:27 PM Debadree Chatterjee <
>>> debad...@gmail.com> wrote:
>>>
 Hey Everyone!

 I am writing to seek some help regarding identifying code patterns
 as you say, almost all the code in these sites seems to be minified
 compacted so quite difficult to find manually does anyone know a 
 better way
 to go about it? like is there an example of maybe modifying some code 
 in
 Chrome to detect these code patterns?

 Yours Sincerely,
 Debadree
 On Monday, May 15, 2023 at 10:06:05 PM UTC+5:30 PhistucK wrote:

> It would be something like this -
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/rDaQdKpWAx8/m/qjTlRNShAgAJ
>
> ☆*PhistucK*
>
>
> On Mon, May 15, 2023 at 10:25 AM Philip Jägenstedt <
> foo...@chromium.org> wrote:
>
>> Hey Andreu,
>>
>> Can you give an example of what the code looks like that calls
>> the methods with a second argument?
>>
>> Best regards,
>> Philip
>>
>> On Fri, May 12, 2023 at 8:51 PM Andreu Botella <
>> abot...@igalia.com> wrote:
>>
>>> jornalmassa.com.br doesn't seem to be calling these methods
>>> with two arguments, at least in my testing. The rest of sites do
>>> occasionally (sometimes with the second argument being 0,
>>> sometimes a different number, sometimes a string), but none seemed 
>>> to break
>>> in my testing.
>>>
>>> Andreu
>>> On 5/12/23 10:38, Philip Jägenstedt wrote:
>>>
>>> It looks like this was spec'd in
>>> http

Re: [blink-dev] Intent to Ship: Add value argument to URLSearchParams's has() and delete()

[Andreu Botella]

As for having a premonition that this would be added, there is at least 
one post in the original Github issue saying that the poster already 
expected the two-argument overload to be supported 
(https://github.com/whatwg/url/issues/335#issuecomment-919700370).


Andreu

On 5/18/23 23:42, PhistucK wrote:
Most of them are just weird, really. I can only imagine they started 
with a .set with an empty string as a second parameter and ended up 
changing to .delete without deleting the second parameter.
(Or they had a premonition and knew there will be a second parameter 
with the specific purpose you want to ship hehe)


I imagine those were outliers, I would not worry much about it (also 
the bound callback is a bit too convoluted to be widely used), but 
that is just me. :)


--
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bfe7d602-9ff5-346a-324b-ae6b4b5af1ec%40igalia.com.

Re: [blink-dev] Intent to Ship: Add value argument to URLSearchParams's has() and delete()

[Debadree Chatterjee]

I tried navigating and clicking around the sites, but they didn't seem to 
be breaking atleast even though this exception is being raised. Are there 
any more investigations I can do?

On Friday, May 19, 2023 at 3:59:21 AM UTC+5:30 abot...@igalia.com wrote:

> As for having a premonition that this would be added, there is at least 
> one post in the original Github issue saying that the poster already 
> expected the two-argument overload to be supported (
> https://github.com/whatwg/url/issues/335#issuecomment-919700370).
>
> Andreu
> On 5/18/23 23:42, PhistucK wrote:
>
> Most of them are just weird, really. I can only imagine they started with 
> a .set with an empty string as a second parameter and ended up changing 
> to .delete without deleting the second parameter.
> (Or they had a premonition and knew there will be a second parameter with 
> the specific purpose you want to ship hehe)
>
> I imagine those were outliers, I would not worry much about it (also the 
> bound callback is a bit too convoluted to be widely used), but that is just 
> me. :)
>
>

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5e40d8a6-2c21-4ed5-8cad-51ad1208928cn%40chromium.org.

Re: [blink-dev] Intent to Ship: Add value argument to URLSearchParams's has() and delete()

[Philip Jägenstedt]

Well, this is a tricky case with no obvious answer. You've found one case
of array.some(...), which most likely will change the behavior of the code.
For the other cases where a second argument is passed is explicitly, it
depends on the value whether it changes behavior, if it's the same value
that was added, then it's fine.

One concrete thing you could do is to refine the use counter to only count
the cases where the 2nd argument results in has() returning false instead
of true, or where delete() doesn't delete anything but would without the
2nd argument. However, I'm not sure that would be informative, if it
reduces the use counter by 10x we'd still be unsure about how serious the
breakage is to users.

In your manual testing of these sites, were you able to confirm the code
paths were taken, and unable to spot anything at all broken on the pages?
Did you compare to how the sites work without the changes?

I would say that given testing of sites that hit the code path, if you
can't find anything at all breaking, then we should try to ship the change.

On Fri, May 19, 2023 at 3:40 PM Debadree Chatterjee 
wrote:

> I tried navigating and clicking around the sites, but they didn't seem to
> be breaking atleast even though this exception is being raised. Are there
> any more investigations I can do?
>
> On Friday, May 19, 2023 at 3:59:21 AM UTC+5:30 abot...@igalia.com wrote:
>
>> As for having a premonition that this would be added, there is at least
>> one post in the original Github issue saying that the poster already
>> expected the two-argument overload to be supported (
>> https://github.com/whatwg/url/issues/335#issuecomment-919700370).
>>
>> Andreu
>> On 5/18/23 23:42, PhistucK wrote:
>>
>> Most of them are just weird, really. I can only imagine they started with
>> a .set with an empty string as a second parameter and ended up changing
>> to .delete without deleting the second parameter.
>> (Or they had a premonition and knew there will be a second parameter with
>> the specific purpose you want to ship hehe)
>>
>> I imagine those were outliers, I would not worry much about it (also the
>> bound callback is a bit too convoluted to be widely used), but that is just
>> me. :)
>>
>>

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYeNJbXWTCa3Uq8s4CLaP-kEyfdvHH62FF_HrU2kEKds9g%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Add value argument to URLSearchParams's has() and delete()

[Debadree Chatterjee]

For basic testing of the sites, I saw no breaking behavior, I did a few 
actions on sites like adding things to the cart, trying to go the login 
flow clicking on navigation, etc. Although I think would need to go a 
little deep on that, Should I submit a new CL for this counter thing? or do 
deeper local testing? 

On Monday, May 22, 2023 at 10:09:26 PM UTC+5:30 Philip Jägenstedt wrote:

> Well, this is a tricky case with no obvious answer. You've found one case 
> of array.some(...), which most likely will change the behavior of the code. 
> For the other cases where a second argument is passed is explicitly, it 
> depends on the value whether it changes behavior, if it's the same value 
> that was added, then it's fine.
>
> One concrete thing you could do is to refine the use counter to only count 
> the cases where the 2nd argument results in has() returning false instead 
> of true, or where delete() doesn't delete anything but would without the 
> 2nd argument. However, I'm not sure that would be informative, if it 
> reduces the use counter by 10x we'd still be unsure about how serious the 
> breakage is to users.
>
> In your manual testing of these sites, were you able to confirm the code 
> paths were taken, and unable to spot anything at all broken on the pages? 
> Did you compare to how the sites work without the changes?
>
> I would say that given testing of sites that hit the code path, if you 
> can't find anything at all breaking, then we should try to ship the change.
>
> On Fri, May 19, 2023 at 3:40 PM Debadree Chatterjee  
> wrote:
>
>> I tried navigating and clicking around the sites, but they didn't seem to 
>> be breaking atleast even though this exception is being raised. Are there 
>> any more investigations I can do?
>>
>> On Friday, May 19, 2023 at 3:59:21 AM UTC+5:30 abot...@igalia.com wrote:
>>
>>> As for having a premonition that this would be added, there is at least 
>>> one post in the original Github issue saying that the poster already 
>>> expected the two-argument overload to be supported (
>>> https://github.com/whatwg/url/issues/335#issuecomment-919700370).
>>>
>>> Andreu
>>> On 5/18/23 23:42, PhistucK wrote:
>>>
>>> Most of them are just weird, really. I can only imagine they started 
>>> with a .set with an empty string as a second parameter and ended up 
>>> changing to .delete without deleting the second parameter.
>>> (Or they had a premonition and knew there will be a second parameter 
>>> with the specific purpose you want to ship hehe)
>>>
>>> I imagine those were outliers, I would not worry much about it (also the 
>>> bound callback is a bit too convoluted to be widely used), but that is just 
>>> me. :)
>>>
>>>

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8bbed241-e28a-4448-8096-bc2bde60f179n%40chromium.org.

Re: [blink-dev] Intent to Ship: Add value argument to URLSearchParams's has() and delete()

[Philip Jägenstedt]

If refining the use counter is easy, that would be good to do, even if we
don't block shipping on getting stable data for the use counter.

But I think that careful local testing is the best way to get a sense for
the risk on this. If you're confident you've hit the code path on the sites
in question, and nothing at all changes for the user, then I think we
should try to ship this.

On Mon, May 22, 2023 at 6:59 PM Debadree Chatterjee 
wrote:

> For basic testing of the sites, I saw no breaking behavior, I did a few
> actions on sites like adding things to the cart, trying to go the login
> flow clicking on navigation, etc. Although I think would need to go a
> little deep on that, Should I submit a new CL for this counter thing? or do
> deeper local testing?
>
> On Monday, May 22, 2023 at 10:09:26 PM UTC+5:30 Philip Jägenstedt wrote:
>
>> Well, this is a tricky case with no obvious answer. You've found one case
>> of array.some(...), which most likely will change the behavior of the code.
>> For the other cases where a second argument is passed is explicitly, it
>> depends on the value whether it changes behavior, if it's the same value
>> that was added, then it's fine.
>>
>> One concrete thing you could do is to refine the use counter to only
>> count the cases where the 2nd argument results in has() returning false
>> instead of true, or where delete() doesn't delete anything but would
>> without the 2nd argument. However, I'm not sure that would be informative,
>> if it reduces the use counter by 10x we'd still be unsure about how serious
>> the breakage is to users.
>>
>> In your manual testing of these sites, were you able to confirm the code
>> paths were taken, and unable to spot anything at all broken on the pages?
>> Did you compare to how the sites work without the changes?
>>
>> I would say that given testing of sites that hit the code path, if you
>> can't find anything at all breaking, then we should try to ship the change.
>>
>> On Fri, May 19, 2023 at 3:40 PM Debadree Chatterjee 
>> wrote:
>>
>>> I tried navigating and clicking around the sites, but they didn't seem
>>> to be breaking atleast even though this exception is being raised. Are
>>> there any more investigations I can do?
>>>
>>> On Friday, May 19, 2023 at 3:59:21 AM UTC+5:30 abot...@igalia.com wrote:
>>>
 As for having a premonition that this would be added, there is at least
 one post in the original Github issue saying that the poster already
 expected the two-argument overload to be supported (
 https://github.com/whatwg/url/issues/335#issuecomment-919700370).

 Andreu
 On 5/18/23 23:42, PhistucK wrote:

 Most of them are just weird, really. I can only imagine they started
 with a .set with an empty string as a second parameter and ended up
 changing to .delete without deleting the second parameter.
 (Or they had a premonition and knew there will be a second parameter
 with the specific purpose you want to ship hehe)

 I imagine those were outliers, I would not worry much about it (also
 the bound callback is a bit too convoluted to be widely used), but that is
 just me. :)



-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYewTpH1QwxR%3D8QdQpQ07ZjbDNJgL51tBWo4c77xb7qpGA%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Add value argument to URLSearchParams's has() and delete()

[Debadree Chatterjee]

Understood!

I am going with the local testing approach for now, I think what I will do 
is raise exceptions if a difference in behavior is noted as Philip 
suggested, and see how many of these example sites raise them. This may 
take a little bit of time I think but trying my best!

Thank You!

On Wednesday, May 24, 2023 at 9:13:04 PM UTC+5:30 Philip Jägenstedt wrote:

> If refining the use counter is easy, that would be good to do, even if we 
> don't block shipping on getting stable data for the use counter.
>
> But I think that careful local testing is the best way to get a sense for 
> the risk on this. If you're confident you've hit the code path on the sites 
> in question, and nothing at all changes for the user, then I think we 
> should try to ship this.
>
> On Mon, May 22, 2023 at 6:59 PM Debadree Chatterjee  
> wrote:
>
>> For basic testing of the sites, I saw no breaking behavior, I did a few 
>> actions on sites like adding things to the cart, trying to go the login 
>> flow clicking on navigation, etc. Although I think would need to go a 
>> little deep on that, Should I submit a new CL for this counter thing? or do 
>> deeper local testing? 
>>
>> On Monday, May 22, 2023 at 10:09:26 PM UTC+5:30 Philip Jägenstedt wrote:
>>
>>> Well, this is a tricky case with no obvious answer. You've found one 
>>> case of array.some(...), which most likely will change the behavior of the 
>>> code. For the other cases where a second argument is passed is explicitly, 
>>> it depends on the value whether it changes behavior, if it's the same value 
>>> that was added, then it's fine.
>>>
>>> One concrete thing you could do is to refine the use counter to only 
>>> count the cases where the 2nd argument results in has() returning false 
>>> instead of true, or where delete() doesn't delete anything but would 
>>> without the 2nd argument. However, I'm not sure that would be informative, 
>>> if it reduces the use counter by 10x we'd still be unsure about how serious 
>>> the breakage is to users.
>>>
>>> In your manual testing of these sites, were you able to confirm the code 
>>> paths were taken, and unable to spot anything at all broken on the pages? 
>>> Did you compare to how the sites work without the changes?
>>>
>>> I would say that given testing of sites that hit the code path, if you 
>>> can't find anything at all breaking, then we should try to ship the change.
>>>
>>> On Fri, May 19, 2023 at 3:40 PM Debadree Chatterjee  
>>> wrote:
>>>
 I tried navigating and clicking around the sites, but they didn't seem 
 to be breaking atleast even though this exception is being raised. Are 
 there any more investigations I can do?

 On Friday, May 19, 2023 at 3:59:21 AM UTC+5:30 abot...@igalia.com 
 wrote:

> As for having a premonition that this would be added, there is at 
> least one post in the original Github issue saying that the poster 
> already 
> expected the two-argument overload to be supported (
> https://github.com/whatwg/url/issues/335#issuecomment-919700370).
>
> Andreu
> On 5/18/23 23:42, PhistucK wrote:
>
> Most of them are just weird, really. I can only imagine they started 
> with a .set with an empty string as a second parameter and ended up 
> changing to .delete without deleting the second parameter.
> (Or they had a premonition and knew there will be a second parameter 
> with the specific purpose you want to ship hehe)
>
> I imagine those were outliers, I would not worry much about it (also 
> the bound callback is a bit too convoluted to be widely used), but that 
> is 
> just me. :)
>
>

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2bfd2135-3bc9-441c-8c7c-6879e371e2edn%40chromium.org.

Re: [blink-dev] Intent to Ship: Add value argument to URLSearchParams's has() and delete()

[Debadree Chatterjee]

Hey Everyone!

Sorry for the delays I followed Philip's suggestion on testing if behavior 
diverged in these sites, I checked this by throwing exceptions if the 
actual return value is different if I used name only or both name and 
value, I am including the code for reference:

bool URLSearchParams::has(const String& name, const String& value, 
ExceptionState& exception_state) const { bool found_match_name = false, 
found_match_name_value = false; for (const auto& param : params_) { if 
(param.first == name) { found_match_name = true; break; } } for (const auto& 
param : params_) { if (param.first == name && (value.IsNull() || 
param.second == value)) { found_match_name_value = true; break; } } if 
(found_match_name != found_match_name_value) { 
exception_state.ThrowException(1, "Divergent behavior"); return false; } 
return found_match_name_value; } void 
URLSearchParams::deleteAllWithNameOrTuple(const String& name, const String& 
value, ExceptionState& exception_state) { for (wtf_size_t i = 0; i < 
params_.size();) { bool match_by_name = params_[i].first == name; bool 
match_by_value = !value.IsNull() && params_[i].second == value; if 
(match_by_name) { if (match_by_value) { params_.EraseAt(i); } else { // It 
would have been deleted if value wasnt there exception_state.ThrowException(
1, "Divergent behavior"); return; } } else { i++; } } RunUpdateSteps(); } 
​
The good news is none of the example sites broke or triggered this 
exception at all, I navigated lightly through all the sites but no 
exception was observed, whereas if I raised an exception whenever double 
variables are passed all the sites would give an exception as you have seen 
in the previous mails. Do let me know if this seems correct!

Regards,
Debadree

On Wednesday, May 24, 2023 at 10:35:59 PM UTC+5:30 Debadree Chatterjee 
wrote:

> Understood!
>
> I am going with the local testing approach for now, I think what I will do 
> is raise exceptions if a difference in behavior is noted as Philip 
> suggested, and see how many of these example sites raise them. This may 
> take a little bit of time I think but trying my best!
>
> Thank You!
>
> On Wednesday, May 24, 2023 at 9:13:04 PM UTC+5:30 Philip Jägenstedt wrote:
>
>> If refining the use counter is easy, that would be good to do, even if we 
>> don't block shipping on getting stable data for the use counter.
>>
>> But I think that careful local testing is the best way to get a sense for 
>> the risk on this. If you're confident you've hit the code path on the sites 
>> in question, and nothing at all changes for the user, then I think we 
>> should try to ship this.
>>
>> On Mon, May 22, 2023 at 6:59 PM Debadree Chatterjee  
>> wrote:
>>
>>> For basic testing of the sites, I saw no breaking behavior, I did a few 
>>> actions on sites like adding things to the cart, trying to go the login 
>>> flow clicking on navigation, etc. Although I think would need to go a 
>>> little deep on that, Should I submit a new CL for this counter thing? or do 
>>> deeper local testing? 
>>>
>>> On Monday, May 22, 2023 at 10:09:26 PM UTC+5:30 Philip Jägenstedt wrote:
>>>
 Well, this is a tricky case with no obvious answer. You've found one 
 case of array.some(...), which most likely will change the behavior of the 
 code. For the other cases where a second argument is passed is explicitly, 
 it depends on the value whether it changes behavior, if it's the same 
 value 
 that was added, then it's fine.

 One concrete thing you could do is to refine the use counter to only 
 count the cases where the 2nd argument results in has() returning false 
 instead of true, or where delete() doesn't delete anything but would 
 without the 2nd argument. However, I'm not sure that would be informative, 
 if it reduces the use counter by 10x we'd still be unsure about how 
 serious 
 the breakage is to users.

 In your manual testing of these sites, were you able to confirm the 
 code paths were taken, and unable to spot anything at all broken on the 
 pages? Did you compare to how the sites work without the changes?

 I would say that given testing of sites that hit the code path, if you 
 can't find anything at all breaking, then we should try to ship the change.

 On Fri, May 19, 2023 at 3:40 PM Debadree Chatterjee  
 wrote:

> I tried navigating and clicking around the sites, but they didn't seem 
> to be breaking atleast even though this exception is being raised. Are 
> there any more investigations I can do?
>
> On Friday, May 19, 2023 at 3:59:21 AM UTC+5:30 abot...@igalia.com 
> wrote:
>
>> As for having a premonition that this would be added, there is at 
>> least one post in the original Github issue saying that the poster 
>> already 
>> expected the two-argument overload to be supported (
>> https://github.com/whatwg/url/issues/335#issuecomment-919700370).

Re: [blink-dev] Intent to Ship: Add value argument to URLSearchParams's has() and delete()

[Philip Jägenstedt]

Hi Debadree,

That's very promising! The code looks right to me, but just to be sure, did
you verify that the exceptions are thrown in a test case where the 2nd
argument makes a difference? It's a bit suspicious when no sites at all
threw the exception :)

Best regards,
Philip

On Tue, May 30, 2023 at 11:45 AM Debadree Chatterjee 
wrote:

> Hey Everyone!
>
> Sorry for the delays I followed Philip's suggestion on testing if behavior
> diverged in these sites, I checked this by throwing exceptions if the
> actual return value is different if I used name only or both name and
> value, I am including the code for reference:
>
> bool URLSearchParams::has(const String& name, const String& value,
> ExceptionState& exception_state) const { bool found_match_name = false,
> found_match_name_value = false; for (const auto& param : params_) { if
> (param.first == name) { found_match_name = true; break; } } for (const
> auto& param : params_) { if (param.first == name && (value.IsNull() ||
> param.second == value)) { found_match_name_value = true; break; } } if
> (found_match_name != found_match_name_value) {
> exception_state.ThrowException(1, "Divergent behavior"); return false; }
> return found_match_name_value; } void
> URLSearchParams::deleteAllWithNameOrTuple(const String& name, const
> String& value, ExceptionState& exception_state) { for (wtf_size_t i = 0;
> i < params_.size();) { bool match_by_name = params_[i].first == name; bool
> match_by_value = !value.IsNull() && params_[i].second == value; if
> (match_by_name) { if (match_by_value) { params_.EraseAt(i); } else { //
> It would have been deleted if value wasnt there
> exception_state.ThrowException(1, "Divergent behavior"); return; } } else
> { i++; } } RunUpdateSteps(); }
> ​
> The good news is none of the example sites broke or triggered this
> exception at all, I navigated lightly through all the sites but no
> exception was observed, whereas if I raised an exception whenever double
> variables are passed all the sites would give an exception as you have seen
> in the previous mails. Do let me know if this seems correct!
>
> Regards,
> Debadree
>
> On Wednesday, May 24, 2023 at 10:35:59 PM UTC+5:30 Debadree Chatterjee
> wrote:
>
>> Understood!
>>
>> I am going with the local testing approach for now, I think what I will
>> do is raise exceptions if a difference in behavior is noted as Philip
>> suggested, and see how many of these example sites raise them. This may
>> take a little bit of time I think but trying my best!
>>
>> Thank You!
>>
>> On Wednesday, May 24, 2023 at 9:13:04 PM UTC+5:30 Philip Jägenstedt wrote:
>>
>>> If refining the use counter is easy, that would be good to do, even if
>>> we don't block shipping on getting stable data for the use counter.
>>>
>>> But I think that careful local testing is the best way to get a sense
>>> for the risk on this. If you're confident you've hit the code path on the
>>> sites in question, and nothing at all changes for the user, then I think we
>>> should try to ship this.
>>>
>>> On Mon, May 22, 2023 at 6:59 PM Debadree Chatterjee 
>>> wrote:
>>>
 For basic testing of the sites, I saw no breaking behavior, I did a few
 actions on sites like adding things to the cart, trying to go the login
 flow clicking on navigation, etc. Although I think would need to go a
 little deep on that, Should I submit a new CL for this counter thing? or do
 deeper local testing?

 On Monday, May 22, 2023 at 10:09:26 PM UTC+5:30 Philip Jägenstedt wrote:

> Well, this is a tricky case with no obvious answer. You've found one
> case of array.some(...), which most likely will change the behavior of the
> code. For the other cases where a second argument is passed is explicitly,
> it depends on the value whether it changes behavior, if it's the same 
> value
> that was added, then it's fine.
>
> One concrete thing you could do is to refine the use counter to only
> count the cases where the 2nd argument results in has() returning false
> instead of true, or where delete() doesn't delete anything but would
> without the 2nd argument. However, I'm not sure that would be informative,
> if it reduces the use counter by 10x we'd still be unsure about how 
> serious
> the breakage is to users.
>
> In your manual testing of these sites, were you able to confirm the
> code paths were taken, and unable to spot anything at all broken on the
> pages? Did you compare to how the sites work without the changes?
>
> I would say that given testing of sites that hit the code path, if you
> can't find anything at all breaking, then we should try to ship the 
> change.
>
> On Fri, May 19, 2023 at 3:40 PM Debadree Chatterjee <
> debad...@gmail.com> wrote:
>
>> I tried navigating and clicking around the sites, but they didn't
>> seem to be breaking atleast even though this exception is being raised. 
>>

Re: [blink-dev] Intent to Ship: Add value argument to URLSearchParams's has() and delete()

[Debadree Chatterjee]

Hey Philip!

In my initial testing, I didn't see any observable change in site behavior, 
but I shall confirm once again!

As for the kill switch and use counter should I update my existing CL to 
include these or make a new one containing the counter to just measure the 
effects?


On Wednesday, May 31, 2023 at 9:28:39 PM UTC+5:30 Philip Jägenstedt wrote:

> Hi Debadree,
>
> Thank you so much for your hard work on this.
>
> To confirm, these two sites were from the 20 listed earlier in this 
> thread, is that right? Now that we've confirmed that these two sites will 
> have a different behavior, can you observe any difference on 
> https://maisonyoko.com/ or https://crossfitdespentes.fr/ with the 
> changes, but without the exception-throwing?
>
> Generally, finding a behavior change in 10% of tested sites is a bit 
> concerning, but if it means that only ~10% of the cases hit by the use 
> counter 
>  are 
> problematic, it could be <0.001% of sites, and we've 
> successfully made breaking changes at that level in the past.
>
> Since you now have the code for throwing an exception, would it be 
> straightforward to turn that into a use counter that we can land and get a 
> better measure of this? I think as discussed previously in this thread, we 
> should considering shipping this with a killswitch and a use counter, so we 
> can both revert and check the usage if we get reports of breakage.
>
> Best regards,
> Philip
>
> On Tue, May 30, 2023 at 5:16 PM Debadree Chatterjee  
> wrote:
>
>> Hey Philip!
>>
>> Even I was surprised, turns out I was wrong about the delete function (so 
>> sorry), I have observed a breakage now,
>>
>> The has function output example:
>> [image: Screenshot 2023-05-30 at 7.36.36 PM.png]
>>
>>
>> The updated delete function:
>>
>> ```c++
>> void URLSearchParams::deleteAllWithNameOrTuple(const String& name,
>>const String& value, 
>> ExceptionState& exception_state) {
>>   std::vector indices_to_remove_with_name_val, 
>> indices_to_remove_with_name;
>>   for (wtf_size_t i = 0; i < params_.size(); i++) {
>> if (params_[i].first == name &&
>> (value.IsNull() || params_[i].second == value)) {
>>   indices_to_remove_with_name_val.push_back(i);
>> }
>>   }
>>
>>   for (wtf_size_t i = 0; i < params_.size(); i++) {
>> if (params_[i].first == name) {
>>   indices_to_remove_with_name.push_back(i);
>> }
>>   }
>>
>>   if (indices_to_remove_with_name_val.size() != 
>> indices_to_remove_with_name.size()) {
>> DLOG(ERROR) << "indices_to_remove_with_name_val.size() != 
>> indices_to_remove_with_name.size()";
>> exception_state.ThrowException(1, "Divergent behavior");
>> return;
>>   }
>>
>>   // match the values of indices_to_remove_with_name_val, 
>> indices_to_remove_with_name
>>   for (size_t i = 0; i < indices_to_remove_with_name_val.size(); i++) {
>> if (indices_to_remove_with_name_val[i] != 
>> indices_to_remove_with_name[i]) {
>>   DLOG(ERROR) << "indices_to_remove_with_name_val[i] != 
>> indices_to_remove_with_name[i]";
>>   exception_state.ThrowException(1, "Divergent behavior");
>>   return;
>> }
>>   }
>>
>>   for (wtf_size_t i = 0; i < params_.size();) {
>> if (params_[i].first == name &&
>> (value.IsNull() || params_[i].second == value)) {
>>   params_.EraseAt(i);
>> } else {
>>   i++;
>> }
>>   }
>>
>>   RunUpdateSteps();
>> }
>> ```
>> The example outputs of the delete function:
>> [image: Screenshot 2023-05-30 at 8.39.03 PM.png]
>>
>> Example Breakages:
>> In https://maisonyoko.com/
>> [image: Screenshot 2023-05-30 at 8.33.59 PM.png]
>> https://crossfitdespentes.fr/
>> [image: Screenshot 2023-05-30 at 8.42.01 PM.png]
>> Other than these sites didn't notice a breakage.
>>
>> seems like the breakages seem to be in the delete function only, so sorry 
>> once again for the mistake before. Do let me know if all this looks ok.
>>
>> Thank You,
>> Debadree
>>
>> On Tuesday, May 30, 2023 at 5:34:18 PM UTC+5:30 Philip Jägenstedt wrote:
>>
>>> Hi Debadree,
>>>
>>> That's very promising! The code looks right to me, but just to be sure, 
>>> did you verify that the exceptions are thrown in a test case where the 2nd 
>>> argument makes a difference? It's a bit suspicious when no sites at all 
>>> threw the exception :)
>>>
>>> Best regards,
>>> Philip
>>>
>>> On Tue, May 30, 2023 at 11:45 AM Debadree Chatterjee  
>>> wrote:
>>>
 Hey Everyone!

 Sorry for the delays I followed Philip's suggestion on testing if 
 behavior diverged in these sites, I checked this by throwing exceptions if 
 the actual return value is different if I used name only or both name and 
 value, I am including the code for reference:

 bool URLSearchParams::has(const String& name, const String& value, 
 ExceptionState& exception_state) const { bool found_match_name = false, 
 

Re: [blink-dev] Intent to Ship: Add value argument to URLSearchParams's has() and delete()

[Mike Taylor]

I wasn't able to find anything obvious in the nuxt org on GitHub, but I 
did post a question in their discussion forum: 
https://github.com/nuxt/nuxt/discussions/21382


On 6/4/23 3:05 PM, Debadree Chatterjee wrote:

Hey!

So I did a more thorough testing! and it seems there is something 
common in both these two sites they are using the Nuxt Framework and 
the breakage in both of them is similar they have videos on the first 
section of their landing page with animations on top of them, due to 
the breakage it seems the video doesn't load! If you look at the call 
sites too the code looks very similar


for https://maisonyoko.com/
Screenshot 2023-06-05 at 12.24.34 AM.png

for https://crossfitdespentes.fr/
Screenshot 2023-06-05 at 12.25.09 AM.png

Both of them nuxt
Screenshot 2023-06-05 at 12.27.12 AM.png
Screenshot 2023-06-05 at 12.27.50 AM.png

I am not familiar with nuxt I will try to get to know about it, but it 
seems like there could be some problem with nuxt, If any reader here 
knows nuxt would love to reach out!


Thank You
Debadree
On Wednesday, May 31, 2023 at 9:38:18 PM UTC+5:30 Debadree Chatterjee 
wrote:


Hey Philip!

In my initial testing, I didn't see any observable change in site
behavior, but I shall confirm once again!

As for the kill switch and use counter should I update my existing
CL to include these or make a new one containing the counter to
just measure the effects?


On Wednesday, May 31, 2023 at 9:28:39 PM UTC+5:30 Philip
Jägenstedt wrote:

Hi Debadree,

Thank you so much for your hard work on this.

To confirm, these two sites were from the 20 listed earlier in
this thread, is that right? Now that we've confirmed that
these two sites will have a different behavior, can you
observe any difference on https://maisonyoko.com/ or
https://crossfitdespentes.fr/ with the changes, but without
the exception-throwing?

Generally, finding a behavior change in 10% of tested sites is
a bit concerning, but if it means that only ~10% of the cases
hit by the use counter

are problematic, it could be <0.001% of sites, and we've
successfully made breaking changes at that level in the past.

Since you now have the code for throwing an exception, would
it be straightforward to turn that into a use counter that we
can land and get a better measure of this? I think as
discussed previously in this thread, we should considering
shipping this with a killswitch and a use counter, so we can
both revert and check the usage if we get reports of breakage.

Best regards,
Philip

On Tue, May 30, 2023 at 5:16 PM Debadree Chatterjee
 wrote:

Hey Philip!

Even I was surprised, turns out I was wrong about the
delete function (so sorry), I have observed a breakage now,

The has function output example:
Screenshot 2023-05-30 at 7.36.36 PM.png


The updated delete function:

```c++
void URLSearchParams::deleteAllWithNameOrTuple(const
String& name,
                                               const
String& value, ExceptionState& exception_state) {
  std::vector indices_to_remove_with_name_val,
indices_to_remove_with_name;
  for (wtf_size_t i = 0; i < params_.size(); i++) {
    if (params_[i].first == name &&
        (value.IsNull() || params_[i].second == value)) {
      indices_to_remove_with_name_val.push_back(i);
    }
  }

  for (wtf_size_t i = 0; i < params_.size(); i++) {
    if (params_[i].first == name) {
      indices_to_remove_with_name.push_back(i);
    }
  }

  if (indices_to_remove_with_name_val.size() !=
indices_to_remove_with_name.size()) {
    DLOG(ERROR) << "indices_to_remove_with_name_val.size()
!= indices_to_remove_with_name.size()";
    exception_state.ThrowException(1, "Divergent behavior");
    return;
  }

  // match the values of indices_to_remove_with_name_val,
indices_to_remove_with_name
  for (size_t i = 0; i <
indices_to_remove_with_name_val.size(); i++) {
    if (indices_to_remove_with_name_val[i] !=
indices_to_remove_with_name[i]) {
      DLOG(ERROR) << "indices_to_remove_with_name_val[i]
!= indices_to_remove_with_name[i]";
      exception_state.ThrowException(1, "Divergent behavior");
      return;
    }
  }

  for (wtf_size_t i = 0; i < params_.size();) {
    if (para

Re: [blink-dev] Intent to Ship: Add value argument to URLSearchParams's has() and delete()

[Debadree Chatterjee]

Hey!

So I tested by stopping raising the exceptions (and executing our new 
normal behaviour) and the behavior is still the same for 
https://maisonyoko.com/ do you see the same for Safari?

On Monday, June 5, 2023 at 7:47:44 PM UTC+5:30 Philip Jägenstedt wrote:

> Hi Debadree,
>
> I also noticed the code was similar for multiple sites, I'm glad you were 
> able to track it down to a common framework, Nuxt. I would suggest filing 
> an issue at https://github.com/nuxt/nuxt about this problem, maybe they 
> can fix it in the next release. Since you've confirmed that some sites 
> won't load the video correctly, and fixing it would require upgrading the 
> framework, it's important to have a fix out there by the time the change is 
> done in Chrome.
>
> Since the WebKit change  was 
> included in STP 171 
> ,
>  
> I tested https://maisonyoko.com/ and https://crossfitdespentes.fr/ in 
> both Safari and STP 171, but I couldn't see any difference. Which video 
> should I expect to not load as a result of this change? I was expecting 
> something to be broken, and then I'd file a WebKit regression bug about it.
>
> As for whether to bake the changes into a single CL or to split it, I 
> don't have a strong opinion.
>
> Best regards,
> Philip
>
> On Sun, Jun 4, 2023 at 9:05 PM Debadree Chatterjee  
> wrote:
>
>> Hey!
>>
>> So I did a more thorough testing! and it seems there is something common 
>> in both these two sites they are using the Nuxt Framework and the breakage 
>> in both of them is similar they have videos on the first section of their 
>> landing page with animations on top of them, due to the breakage it seems 
>> the video doesn't load! If you look at the call sites too the code looks 
>> very similar
>>
>> for https://maisonyoko.com/
>> [image: Screenshot 2023-06-05 at 12.24.34 AM.png]
>>
>> for https://crossfitdespentes.fr/
>> [image: Screenshot 2023-06-05 at 12.25.09 AM.png]
>>
>> Both of them nuxt 
>> [image: Screenshot 2023-06-05 at 12.27.12 AM.png]
>> [image: Screenshot 2023-06-05 at 12.27.50 AM.png]
>>
>> I am not familiar with nuxt I will try to get to know about it, but it 
>> seems like there could be some problem with nuxt, If any reader here knows 
>> nuxt would love to reach out!
>>
>> Thank You
>> Debadree
>> On Wednesday, May 31, 2023 at 9:38:18 PM UTC+5:30 Debadree Chatterjee 
>> wrote:
>>
>>> Hey Philip!
>>>
>>> In my initial testing, I didn't see any observable change in site 
>>> behavior, but I shall confirm once again!
>>>
>>> As for the kill switch and use counter should I update my existing CL to 
>>> include these or make a new one containing the counter to just measure the 
>>> effects?
>>>
>>>
>>> On Wednesday, May 31, 2023 at 9:28:39 PM UTC+5:30 Philip Jägenstedt 
>>> wrote:
>>>
 Hi Debadree,

 Thank you so much for your hard work on this.

 To confirm, these two sites were from the 20 listed earlier in this 
 thread, is that right? Now that we've confirmed that these two sites will 
 have a different behavior, can you observe any difference on 
 https://maisonyoko.com/ or https://crossfitdespentes.fr/ with the 
 changes, but without the exception-throwing?

 Generally, finding a behavior change in 10% of tested sites is a bit 
 concerning, but if it means that only ~10% of the cases hit by the use 
 counter 
  
 are problematic, it could be <0.001% of sites, and we've 
 successfully made breaking changes at that level in the past.

 Since you now have the code for throwing an exception, would it be 
 straightforward to turn that into a use counter that we can land and get a 
 better measure of this? I think as discussed previously in this thread, we 
 should considering shipping this with a killswitch and a use counter, so 
 we 
 can both revert and check the usage if we get reports of breakage.

 Best regards,
 Philip

 On Tue, May 30, 2023 at 5:16 PM Debadree Chatterjee  
 wrote:

> Hey Philip!
>
> Even I was surprised, turns out I was wrong about the delete function 
> (so sorry), I have observed a breakage now,
>
> The has function output example:
> [image: Screenshot 2023-05-30 at 7.36.36 PM.png]
>
>
> The updated delete function:
>
> ```c++
> void URLSearchParams::deleteAllWithNameOrTuple(const String& name,
>const String& value, 
> ExceptionState& exception_state) {
>   std::vector indices_to_remove_with_name_val, 
> indices_to_remove_with_name;
>   for (wtf_size_t i = 0; i < params_.size(); i++) {
> if (params_[i].first == name &&
> (value.IsNull() || params_[i].second == value)) {
>   indi

Re: [blink-dev] Intent to Ship: Add value argument to URLSearchParams's has() and delete()

[Simon Lecutiez]

Hello,

> I am still analyzing if this is a library issue or maybe its some 
specific style of writing nuxt

Both websites were made by the same agency (Akaru ), so 
it could even be a homemade library or a single developer’s style ;)

Hope it helps,
Simon

Le lundi 5 juin 2023 à 17:07:47 UTC+2, Debadree Chatterjee a écrit :

> Hey!
>
> I have attached the difference in how they look for ttps://maisonyoko.com/ 
>  note that the background video doesn't load 
> maybe since for local testing I am raising exceptions thats why its the 
> causing issue (I am checking this) as for the nuxt issue I am still 
> analyzing if this is a library issue or maybe its some specific style of 
> writing nuxt
>
> As for the CL i shall then include both the runtime flag and use counter 
> in the same CL hopefully by tomorrow
>
> Regards,
> Debadree
> On Monday, June 5, 2023 at 7:47:44 PM UTC+5:30 Philip Jägenstedt wrote:
>
>> Hi Debadree,
>>
>> I also noticed the code was similar for multiple sites, I'm glad you were 
>> able to track it down to a common framework, Nuxt. I would suggest filing 
>> an issue at https://github.com/nuxt/nuxt about this problem, maybe they 
>> can fix it in the next release. Since you've confirmed that some sites 
>> won't load the video correctly, and fixing it would require upgrading the 
>> framework, it's important to have a fix out there by the time the change is 
>> done in Chrome.
>>
>> Since the WebKit change  
>> was included in STP 171 
>> ,
>>  
>> I tested https://maisonyoko.com/ and https://crossfitdespentes.fr/ in 
>> both Safari and STP 171, but I couldn't see any difference. Which video 
>> should I expect to not load as a result of this change? I was expecting 
>> something to be broken, and then I'd file a WebKit regression bug about it.
>>
>> As for whether to bake the changes into a single CL or to split it, I 
>> don't have a strong opinion.
>>
>> Best regards,
>> Philip
>>
>> On Sun, Jun 4, 2023 at 9:05 PM Debadree Chatterjee  
>> wrote:
>>
>>> Hey!
>>>
>>> So I did a more thorough testing! and it seems there is something common 
>>> in both these two sites they are using the Nuxt Framework and the breakage 
>>> in both of them is similar they have videos on the first section of their 
>>> landing page with animations on top of them, due to the breakage it seems 
>>> the video doesn't load! If you look at the call sites too the code looks 
>>> very similar
>>>
>>> for https://maisonyoko.com/
>>> [image: Screenshot 2023-06-05 at 12.24.34 AM.png]
>>>
>>> for https://crossfitdespentes.fr/
>>> [image: Screenshot 2023-06-05 at 12.25.09 AM.png]
>>>
>>> Both of them nuxt 
>>> [image: Screenshot 2023-06-05 at 12.27.12 AM.png]
>>> [image: Screenshot 2023-06-05 at 12.27.50 AM.png]
>>>
>>> I am not familiar with nuxt I will try to get to know about it, but it 
>>> seems like there could be some problem with nuxt, If any reader here knows 
>>> nuxt would love to reach out!
>>>
>>> Thank You
>>> Debadree
>>> On Wednesday, May 31, 2023 at 9:38:18 PM UTC+5:30 Debadree Chatterjee 
>>> wrote:
>>>
 Hey Philip!

 In my initial testing, I didn't see any observable change in site 
 behavior, but I shall confirm once again!

 As for the kill switch and use counter should I update my existing CL 
 to include these or make a new one containing the counter to just measure 
 the effects?


 On Wednesday, May 31, 2023 at 9:28:39 PM UTC+5:30 Philip Jägenstedt 
 wrote:

> Hi Debadree,
>
> Thank you so much for your hard work on this.
>
> To confirm, these two sites were from the 20 listed earlier in this 
> thread, is that right? Now that we've confirmed that these two sites will 
> have a different behavior, can you observe any difference on 
> https://maisonyoko.com/ or https://crossfitdespentes.fr/ with the 
> changes, but without the exception-throwing?
>
> Generally, finding a behavior change in 10% of tested sites is a bit 
> concerning, but if it means that only ~10% of the cases hit by the use 
> counter 
>  
> are problematic, it could be <0.001% of sites, and we've 
> successfully made breaking changes at that level in the past.
>
> Since you now have the code for throwing an exception, would it be 
> straightforward to turn that into a use counter that we can land and get 
> a 
> better measure of this? I think as discussed previously in this thread, 
> we 
> should considering shipping this with a killswitch and a use counter, so 
> we 
> can both revert and check the usage if we get reports of breakage.
>
> Best regards,
> Philip
>
> On Tue, May 30, 2023 at 5:16 PM Debadre

Re: [blink-dev] Intent to Ship: Add value argument to URLSearchParams's has() and delete()

[Debadree Chatterjee]

Thank you so much for finding out simon!! so then nuxt is probably not to 
blame here 

On Tuesday, June 6, 2023 at 8:39:51 PM UTC+5:30 Simon Lecutiez wrote:

> Hello,
>
> > I am still analyzing if this is a library issue or maybe its some 
> specific style of writing nuxt
>
> Both websites were made by the same agency (Akaru ), 
> so it could even be a homemade library or a single developer’s style ;)
>
> Hope it helps,
> Simon
>
> Le lundi 5 juin 2023 à 17:07:47 UTC+2, Debadree Chatterjee a écrit :
>
>> Hey!
>>
>> I have attached the difference in how they look for 
>> ttps://maisonyoko.com/  note that the 
>> background video doesn't load maybe since for local testing I am raising 
>> exceptions thats why its the causing issue (I am checking this) as for the 
>> nuxt issue I am still analyzing if this is a library issue or maybe its 
>> some specific style of writing nuxt
>>
>> As for the CL i shall then include both the runtime flag and use counter 
>> in the same CL hopefully by tomorrow
>>
>> Regards,
>> Debadree
>> On Monday, June 5, 2023 at 7:47:44 PM UTC+5:30 Philip Jägenstedt wrote:
>>
>>> Hi Debadree,
>>>
>>> I also noticed the code was similar for multiple sites, I'm glad you 
>>> were able to track it down to a common framework, Nuxt. I would suggest 
>>> filing an issue at https://github.com/nuxt/nuxt about this problem, 
>>> maybe they can fix it in the next release. Since you've confirmed that some 
>>> sites won't load the video correctly, and fixing it would require upgrading 
>>> the framework, it's important to have a fix out there by the time the 
>>> change is done in Chrome.
>>>
>>> Since the WebKit change  
>>> was included in STP 171 
>>> ,
>>>  
>>> I tested https://maisonyoko.com/ and https://crossfitdespentes.fr/ in 
>>> both Safari and STP 171, but I couldn't see any difference. Which video 
>>> should I expect to not load as a result of this change? I was expecting 
>>> something to be broken, and then I'd file a WebKit regression bug about it.
>>>
>>> As for whether to bake the changes into a single CL or to split it, I 
>>> don't have a strong opinion.
>>>
>>> Best regards,
>>> Philip
>>>
>>> On Sun, Jun 4, 2023 at 9:05 PM Debadree Chatterjee  
>>> wrote:
>>>
 Hey!

 So I did a more thorough testing! and it seems there is something 
 common in both these two sites they are using the Nuxt Framework and the 
 breakage in both of them is similar they have videos on the first section 
 of their landing page with animations on top of them, due to the breakage 
 it seems the video doesn't load! If you look at the call sites too the 
 code 
 looks very similar

 for https://maisonyoko.com/
 [image: Screenshot 2023-06-05 at 12.24.34 AM.png]

 for https://crossfitdespentes.fr/
 [image: Screenshot 2023-06-05 at 12.25.09 AM.png]

 Both of them nuxt 
 [image: Screenshot 2023-06-05 at 12.27.12 AM.png]
 [image: Screenshot 2023-06-05 at 12.27.50 AM.png]

 I am not familiar with nuxt I will try to get to know about it, but it 
 seems like there could be some problem with nuxt, If any reader here knows 
 nuxt would love to reach out!

 Thank You
 Debadree
 On Wednesday, May 31, 2023 at 9:38:18 PM UTC+5:30 Debadree Chatterjee 
 wrote:

> Hey Philip!
>
> In my initial testing, I didn't see any observable change in site 
> behavior, but I shall confirm once again!
>
> As for the kill switch and use counter should I update my existing CL 
> to include these or make a new one containing the counter to just measure 
> the effects?
>
>
> On Wednesday, May 31, 2023 at 9:28:39 PM UTC+5:30 Philip Jägenstedt 
> wrote:
>
>> Hi Debadree,
>>
>> Thank you so much for your hard work on this.
>>
>> To confirm, these two sites were from the 20 listed earlier in this 
>> thread, is that right? Now that we've confirmed that these two sites 
>> will 
>> have a different behavior, can you observe any difference on 
>> https://maisonyoko.com/ or https://crossfitdespentes.fr/ with the 
>> changes, but without the exception-throwing?
>>
>> Generally, finding a behavior change in 10% of tested sites is a bit 
>> concerning, but if it means that only ~10% of the cases hit by the use 
>> counter 
>>  
>> are problematic, it could be <0.001% of sites, and we've 
>> successfully made breaking changes at that level in the past.
>>
>> Since you now have the code for throwing an exception, would it be 
>> straightforward to turn that into a use counter that we can land and get 
>> a 
>> better measure of this? I think as d

Re: [blink-dev] Intent to Ship: Add value argument to URLSearchParams's has() and delete()

[Debadree Chatterjee]

hello!

I checked in safari technology preview pretty weird I dont observe the same 
breaking behaviour, I am trying to investigate why that is so!

On Tuesday, June 6, 2023 at 8:49:22 PM UTC+5:30 Debadree Chatterjee wrote:

> Thank you so much for finding out simon!! so then nuxt is probably not to 
> blame here 
>
> On Tuesday, June 6, 2023 at 8:39:51 PM UTC+5:30 Simon Lecutiez wrote:
>
>> Hello,
>>
>> > I am still analyzing if this is a library issue or maybe its some 
>> specific style of writing nuxt
>>
>> Both websites were made by the same agency (Akaru ), 
>> so it could even be a homemade library or a single developer’s style ;)
>>
>> Hope it helps,
>> Simon
>>
>> Le lundi 5 juin 2023 à 17:07:47 UTC+2, Debadree Chatterjee a écrit :
>>
>>> Hey!
>>>
>>> I have attached the difference in how they look for 
>>> ttps://maisonyoko.com/  note that the 
>>> background video doesn't load maybe since for local testing I am raising 
>>> exceptions thats why its the causing issue (I am checking this) as for the 
>>> nuxt issue I am still analyzing if this is a library issue or maybe its 
>>> some specific style of writing nuxt
>>>
>>> As for the CL i shall then include both the runtime flag and use counter 
>>> in the same CL hopefully by tomorrow
>>>
>>> Regards,
>>> Debadree
>>> On Monday, June 5, 2023 at 7:47:44 PM UTC+5:30 Philip Jägenstedt wrote:
>>>
 Hi Debadree,

 I also noticed the code was similar for multiple sites, I'm glad you 
 were able to track it down to a common framework, Nuxt. I would suggest 
 filing an issue at https://github.com/nuxt/nuxt about this problem, 
 maybe they can fix it in the next release. Since you've confirmed that 
 some 
 sites won't load the video correctly, and fixing it would require 
 upgrading 
 the framework, it's important to have a fix out there by the time the 
 change is done in Chrome.

 Since the WebKit change  
 was included in STP 171 
 ,
  
 I tested https://maisonyoko.com/ and https://crossfitdespentes.fr/ in 
 both Safari and STP 171, but I couldn't see any difference. Which video 
 should I expect to not load as a result of this change? I was expecting 
 something to be broken, and then I'd file a WebKit regression bug about it.

 As for whether to bake the changes into a single CL or to split it, I 
 don't have a strong opinion.

 Best regards,
 Philip

 On Sun, Jun 4, 2023 at 9:05 PM Debadree Chatterjee  
 wrote:

> Hey!
>
> So I did a more thorough testing! and it seems there is something 
> common in both these two sites they are using the Nuxt Framework and the 
> breakage in both of them is similar they have videos on the first section 
> of their landing page with animations on top of them, due to the breakage 
> it seems the video doesn't load! If you look at the call sites too the 
> code 
> looks very similar
>
> for https://maisonyoko.com/
> [image: Screenshot 2023-06-05 at 12.24.34 AM.png]
>
> for https://crossfitdespentes.fr/
> [image: Screenshot 2023-06-05 at 12.25.09 AM.png]
>
> Both of them nuxt 
> [image: Screenshot 2023-06-05 at 12.27.12 AM.png]
> [image: Screenshot 2023-06-05 at 12.27.50 AM.png]
>
> I am not familiar with nuxt I will try to get to know about it, but it 
> seems like there could be some problem with nuxt, If any reader here 
> knows 
> nuxt would love to reach out!
>
> Thank You
> Debadree
> On Wednesday, May 31, 2023 at 9:38:18 PM UTC+5:30 Debadree Chatterjee 
> wrote:
>
>> Hey Philip!
>>
>> In my initial testing, I didn't see any observable change in site 
>> behavior, but I shall confirm once again!
>>
>> As for the kill switch and use counter should I update my existing CL 
>> to include these or make a new one containing the counter to just 
>> measure 
>> the effects?
>>
>>
>> On Wednesday, May 31, 2023 at 9:28:39 PM UTC+5:30 Philip Jägenstedt 
>> wrote:
>>
>>> Hi Debadree,
>>>
>>> Thank you so much for your hard work on this.
>>>
>>> To confirm, these two sites were from the 20 listed earlier in this 
>>> thread, is that right? Now that we've confirmed that these two sites 
>>> will 
>>> have a different behavior, can you observe any difference on 
>>> https://maisonyoko.com/ or https://crossfitdespentes.fr/ with the 
>>> changes, but without the exception-throwing?
>>>
>>> Generally, finding a behavior change in 10% of tested sites is a bit 
>>> concerning, but if it means that only ~10% of the cases hit by the use 
>>> counter 
>>> 

Re: [blink-dev] Intent to Ship: Add value argument to URLSearchParams's has() and delete()

[Debadree Chatterjee]

Hey everyone!

Indeed the site doesn't load properly even if we use unmodified chromium as 
Phistuck suggested! so sorry for the confusion caused. I have updated my 
CL https://chromium-review.googlesource.com/c/chromium/src/+/4519040 to 
include both use counters and a runtime flag and am awaiting necessary 
approvals so we can move forward! 

Thank you!

Regards,
Debadree


On Tuesday, June 13, 2023 at 3:02:40 PM UTC+5:30 mk...@chromium.org wrote:

> LGTM3. Please do make sure this is behind a feature flag just in case the 
> use counters are higher than expected.
>
> -mike
>
>
> On Tue, Jun 13, 2023 at 10:57 AM Yoav Weiss  wrote:
>
>> LGTM2
>>
>> On Tue, Jun 13, 2023 at 10:42 AM Philip Jägenstedt  
>> wrote:
>>
>>> Indeed, Chromium isn’t built with all of the same codecs, so that’s the 
>>> most likely explanation for the video not playing.
>>>
>>> I would say that if these pages aren’t broken in Safari then that’s 
>>> evidence enough that it’s not a serious failure mode.
>>>
>>> At this point I think we know enough about the risks here.
>>>
>>> LGTM1 to ship with the use counters added so we can get stats on how 
>>> common it is if we need to revert/disable after a regression.
>>>
>>> I would suggest re-testing these sites with Chrome Canary after the 
>>> change lands to confirm no visible breakage.
>>>
>>> On Tue, 13 Jun 2023 at 10:20 PhistucK  wrote:
>>>
 Does it work with an unmodified Chromium (from 
 download-chromium.appspot.com for example)?
 If not, then it might just require non-free codecs, Widevine and 
 similar.

 ☆*PhistucK*


 On Mon, Jun 12, 2023 at 7:21 PM Debadree Chatterjee  
 wrote:

> Hey everyone!
>
> sorry for the delays, I tested things locally with both Safari tech 
> preview and my Chromium changes, and unfortunately, I see the breakage in 
> the videos still and I don't see this happening on Safari, is it possible 
> that my local Chromium config is to blame here? I tested my changes 
> against 
> the WPTs and the wpt suite seems to pass, would anyone try local testing 
> with my CL here 
> https://chromium-review.googlesource.com/c/chromium/src/+/4519040 to 
> see if this reproduces for you? I have also updated the CL to include a 
> use 
> counter for the change so if anyone would review it would be great! PFA 
> how 
> it looks on my chromium[image: Screenshot 2023-06-12 at 11.44.29 
> PM.png]
> note the player error in the background.
>
> Thank You!
>
> Regards,
> Debadree
>
> On Wednesday, June 7, 2023 at 11:44:12 PM UTC+5:30 Debadree Chatterjee 
> wrote:
>
>> hello!
>>
>> I checked in safari technology preview pretty weird I dont observe 
>> the same breaking behaviour, I am trying to investigate why that is so!
>>
>> On Tuesday, June 6, 2023 at 8:49:22 PM UTC+5:30 Debadree Chatterjee 
>> wrote:
>>
>>> Thank you so much for finding out simon!! so then nuxt is probably 
>>> not to blame here 
>>>
>>> On Tuesday, June 6, 2023 at 8:39:51 PM UTC+5:30 Simon Lecutiez wrote:
>>>
 Hello,

 > I am still analyzing if this is a library issue or maybe its some 
 specific style of writing nuxt

 Both websites were made by the same agency (Akaru 
 ), so it could even be a homemade library or a 
 single developer’s style ;)

 Hope it helps,
 Simon

 Le lundi 5 juin 2023 à 17:07:47 UTC+2, Debadree Chatterjee a écrit :

> Hey!
>
> I have attached the difference in how they look for 
> ttps://maisonyoko.com/  note that the 
> background video doesn't load maybe since for local testing I am 
> raising 
> exceptions thats why its the causing issue (I am checking this) as 
> for the 
> nuxt issue I am still analyzing if this is a library issue or maybe 
> its 
> some specific style of writing nuxt
>
> As for the CL i shall then include both the runtime flag and use 
> counter in the same CL hopefully by tomorrow
>
> Regards,
> Debadree
> On Monday, June 5, 2023 at 7:47:44 PM UTC+5:30 Philip Jägenstedt 
> wrote:
>
>> Hi Debadree,
>>
>> I also noticed the code was similar for multiple sites, I'm glad 
>> you were able to track it down to a common framework, Nuxt. I would 
>> suggest 
>> filing an issue at https://github.com/nuxt/nuxt about this 
>> problem, maybe they can fix it in the next release. Since you've 
>> confirmed 
>> that some sites won't load the video correctly, and fixing it would 
>> require 
>> upgrading the framework, it's important to have a fix out there by 
>> the time