from:"Debadree Chatterjee"

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

2023-05-11 Thread 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 

Motivation
This particular addition to the standards has been a long requested and gives 
developers much needed flexibility in the has() and delete() apis allowing to 
delete specific tuples.


Initial public proposal
None

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: Has shipped (https://github.com/WebKit/WebKit/pull/13500)

Web developers: No signals

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?

Unknown but most probably no.


Debuggability
None

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

Flag name
None


Requires code in //chrome?
False

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

Estimated milestones
No milestones specified


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

Links to previous Intent discussions


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/CFBE060E-9D1C-4B8D-A4FB-B0279D73E6F4%40gmail.com.

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

2023-05-12 Thread 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.

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

2023-05-12 Thread Debadree Chatterjee

Given that the feature is pretty small it was recommended to me to directly 
take it to intent to ship stage

Thank You!

On Friday, May 12, 2023 at 1:00:08 PM UTC+5:30 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 
> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink>
>
> 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 
> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
> ?
> 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 
> <https://chromestatus.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/cbd69f38-9477-44d5-92cc-f45ce497be55n%40chromium.org.

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

2023-05-12 Thread 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 
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink>
>>
>> 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 
>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>> ?
>> 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 
>> <https://chromestatus.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+...@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
>>  
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/A73025EA-70D7-4818-9CFF-AE14B48875F0%40gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
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()

2023-05-12 Thread 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 
>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink>
>>>
>>> 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 
>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>>> ?
>>> 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 (

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

2023-05-15 Thread Debadree Chatterjee

Hey! so sorry for missing it I filed for moving it to the Intent to Ship 
stage since it was recommended that it's small enough a feature to move to 
that stage 
here: https://groups.google.com/a/chromium.org/g/blink-dev/c/rDaQdKpWAx8

I have also filed for a Mozilla standards position as you mention!

So sorry once again for not mentioning the same here (new to the process 
hence had gotten confused intially)

Yours Sincerely,
Debadree

On Monday, May 15, 2023 at 2:02:09 PM UTC+5:30 yoav...@chromium.org wrote:

> Thanks for working towards alignment here! :)
>
> On Thu, May 11, 2023 at 2:25 PM 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 
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink>
>>
>> Motivation
>> This particular addition to the standards has been a long requested and 
>> gives developers much needed flexibility in the has() and delete() apis 
>> allowing to delete specific tuples.
>>
>>
>> Initial public proposalNone
>>
>> 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
>>
>
> The usecounter 
> <https://chromestatus.com/metrics/feature/timeline/popularity/4478> shows 
> usage at 0.006% of page views, which is low but not low enough for this to 
> be trivial.
> At the same time, the list of origins that show this in the HTTPArchive is 
> not huge and rather homogenic. So some sampling of these sites can go a 
> long way to reassure the API owners regarding lack of breakage once this 
> reaches the "Intent to ship" phase.
>  
>
>>
>> *Gecko*: No signal
>>
>
> It might be worthwhile to file for a signal - https://bit.ly/blink-signals
>  
>
>>
>> *WebKit*: Has shipped (https://github.com/WebKit/WebKit/pull/13500)
>>
>> *Web developers*: No signals
>>
>> *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?
>>
>> Unknown but most probably no.
>>
>>
>>
>> Debuggability
>>
>> None
>>
>> Is this feature fully tested by web-platform-tests 
>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>> ?
>> Yes
>>
>> Flag name
>> None
>>
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1442916
>>
>> Estimated milestones
>> No milestones specified
>>
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5147732899004416
>>
>> Links to previous Intent discussions
>>
>> This intent message was generated by Chrome Platform Status 
>> <https://chromestatus.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+...@chromium.org.
>> To view this discussion on the web visit 
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CFBE060E-9D1C-4B8D-A4FB-B0279D73E6F4%40gmail.com
>>  
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CFBE060E-9D1C-4B8D-A4FB-B0279D73E6F4%40gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
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/5a598b1f-4898-4c3c-b8bf-80e199fd0b8cn%40chromium.org.

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

2023-05-15 Thread 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 
>>> <https://bugs.chromium.org/p/chromium/issues/list?q=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 
>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>>> ? 
>>> 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/51477328990044

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

2023-05-17 Thread 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 
>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=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 
>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>>>> ? 
>>>> Yes
>>>>
>>>> Flag name 
>>>>
>>>> Requires code in //chrome? F

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

2023-05-17 Thread 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 
>>>>>

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

2023-05-17 Thread 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.
>>>>>>>>
>>>>

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

2023-05-17 Thread 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
>>>>>>>>
>>>>>>>> ☆*Phis

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

2023-05-19 Thread 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()

2023-05-22 Thread 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()

2023-05-24 Thread 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()

2023-05-30 Thread 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:
>>>>

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

2023-05-31 Thread 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 
> <https://chromestatus.com/metrics/feature/timeline/popularity/4478> 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

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

2023-06-05 Thread 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 <https://github.com/WebKit/WebKit/pull/13500> was 
> included in STP 171 
> <https://developer.apple.com/documentation/safari-technology-preview-release-notes/stp-release-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 
>>>> <https://chromestatus.com/metrics/feature/timeline/popularity/4478> 
>>>> 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 Cha

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

2023-06-06 Thread 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 <https://akaru.fr/>), 
> 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/ <https://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 <https://github.com/WebKit/WebKit/pull/13500> 
>>> was included in STP 171 
>>> <https://developer.apple.com/documentation/safari-technology-preview-release-notes/stp-release-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,
>&g

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

2023-06-07 Thread 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 <https://akaru.fr/>), 
>> 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/ <https://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 <https://github.com/WebKit/WebKit/pull/13500> 
>>>> was included in STP 171 
>>>> <https://developer.apple.com/documentation/safari-technology-preview-release-notes/stp-release-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:
>>>>>
>>>>>> H

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

2023-06-13 Thread 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 
>>>>>>>> <https://akaru.fr/>), 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 :
>>>>>>>>
>>>>>>>>>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

20 matches

Site Navigation

Mail list logo

Footer information