Re: [blink-dev] Intent to Ship: CSS font-variant-position property

[David Baron]

I was trying to avoid being too specific about what would be worth
measuring both because I haven't taken the time to think through all the
details, and because other folks on this thread have a lot of domain
expertise that can help figure out what makes sense.  I just wanted to
point out that if you are measuring stuff, it's worth considering that it
may be useful to measure something about usage of system versus downloaded
fonts in order to understand variation between machines (which I agree is
at least mostly variation between platforms).

-David

On Tue, May 30, 2023 at 11:44 AM Dominik Röttsches  wrote:

> Hi David and Rick,
>
> It's a shame to me to be holding back interop on the case of fonts having
>> the superscript or subscript glyphs out of fear for the case where they
>> don't. Perhaps we can treat the case of font-variant-position being used
>> with fonts that lack the glyphs as a site bug that we can work to address
>> independently? Personally, as long as Safari and Chrome behave the same
>> here, I'm skeptical that the lack of synthesis would turn into a
>> non-trivial problem in practice.
>
>
> I think expectations as to what should the browser do vs. what is
> reasonably expected of site owners in terms of font selection and visual
> delivery is on a spectrum (font fallback being a similar case).
> In the case of using font-variant-position, I tend to agree with Rick: I'd
> consider using font-variant-position without a suitable font is a site bug.
> Safari seems to be of the same opinion by shipping font-variant-position
> without synthesis.
>
> If we were to ship without synthesis, would it be practical to have a
>> UseCounter which measures how often we see font-variant-position used with
>> a font that lacks the glyphs? This would tell us how important the bug is.
>> If it remains really rare, then IMHO we've probably already wasted more
>> energy worrying about it than it's worth. If it becomes more common over
>> time then I think we have a variety of options, chiefly implementing
>> synthesis, but also raising awareness with devtools features, UKM-based
>> site-specific outreach, and possibly even interventions of some form (like
>> using a fallback font?).
>
>
> It's difficult to measure the visual end result accurately:
> Only at shaping time we know exactly which font binary is used. This in
> HarfBuzzShaper and we can determine whether the `sups` and `subs`
> OpenType features
>  
> are
> requested (we would need extra code for determining whether these features
> were requested through font-variant-position: or font-feature-settings).
> Then we can determine whether the font has such a feature in its shaping
> tables. The difficulty is: We reach the shaping code lots of times for
> every relayout or web font arriving. So initially, we may shape with a
> fallback font before the web font arrives, which affects the measurement
> result. Measuring in shaping is not synchronized with a stable layout stage
> or something like a "done" state of the page. So we could get to an
> approximation, but in shaping we can't currently determine what's the last
> state that "stayed" and was perceived by the user.
>
> David wrote:
>
>> So if it makes sense to add use counters to understand the compatibility
>> implications here, I think it may be worth adding what we would need to
>> understand the breakdown of how many sites are using this in a way that (a)
>> is interoperable across browsers/machines versus (b) is broken in some
>> browsers and working on others versus (c) is broken on some machines and
>> working on other machines, even using the same browser.  I suspect this
>> would mean something like measuring how often we see font-variant-position
>> used with a system font versus a downloadable font.  (This might also need
>> to be recorded along with the data on whether the font has or lacks the
>> superscript/subscript glyphs, because the intersection of the two might be
>> interesting.)
>
>
> I do agree this feature is most meaningful in combination with web fonts.
> Or even more specifically: Selecting font-variant-position needs to be
> carefully synced with the selected font and making sure the exact font has
> high chances of getting loaded.
> Do I understand correctly you suggest measuring font-variant-position
> usage with system fonts vs. web fonts because of the differences between
> machines? Or did you also mean platforms?
> The system font set used from the web is relatively stable between
> machines, meaning: Windows fonts are usually similar across machines (when
> it comes to those selected from the web), so are Mac fonts.
>
> In any event, I did a quick check:
> Mac: Helvetica, Times, and Courier New on Mac, and as far as I can tell,
> neither has a specific superscript or subscript OpenType or AAT font
> feature.
> Windows: Out of Arial, Courier, Times, Verdana only Verdana has subscript

Re: [blink-dev] Intent to Ship: CSS font-variant-position property

[Rick Byers]

Thanks David, Dominik.

As API owners I think our job is largely about evaluating interop risk vs.
platform benefit. It's hard for me to evaluate the benefit of this feature
without synthesis (how big of a problem is webfont fallback in practice?).
But it seems clear to me that adding this feature to Chrome matching Safari
(but not Firefox) is a net reduction in interop risk compared to the status
quo of all three browsers behaving differently due to Chrome's lack of
support. So, while we could have all sorts of debate and discussion about
what more to do, as-is this passes our I2S bar for me.

LGTM1. Sorry for the long delay.

Rick


On Tue, May 30, 2023 at 11:44 AM Dominik Röttsches  wrote:

> Hi David and Rick,
>
> It's a shame to me to be holding back interop on the case of fonts having
>> the superscript or subscript glyphs out of fear for the case where they
>> don't. Perhaps we can treat the case of font-variant-position being used
>> with fonts that lack the glyphs as a site bug that we can work to address
>> independently? Personally, as long as Safari and Chrome behave the same
>> here, I'm skeptical that the lack of synthesis would turn into a
>> non-trivial problem in practice.
>
>
> I think expectations as to what should the browser do vs. what is
> reasonably expected of site owners in terms of font selection and visual
> delivery is on a spectrum (font fallback being a similar case).
> In the case of using font-variant-position, I tend to agree with Rick: I'd
> consider using font-variant-position without a suitable font is a site bug.
> Safari seems to be of the same opinion by shipping font-variant-position
> without synthesis.
>
> If we were to ship without synthesis, would it be practical to have a
>> UseCounter which measures how often we see font-variant-position used with
>> a font that lacks the glyphs? This would tell us how important the bug is.
>> If it remains really rare, then IMHO we've probably already wasted more
>> energy worrying about it than it's worth. If it becomes more common over
>> time then I think we have a variety of options, chiefly implementing
>> synthesis, but also raising awareness with devtools features, UKM-based
>> site-specific outreach, and possibly even interventions of some form (like
>> using a fallback font?).
>
>
> It's difficult to measure the visual end result accurately:
> Only at shaping time we know exactly which font binary is used. This in
> HarfBuzzShaper and we can determine whether the `sups` and `subs`
> OpenType features
>  
> are
> requested (we would need extra code for determining whether these features
> were requested through font-variant-position: or font-feature-settings).
> Then we can determine whether the font has such a feature in its shaping
> tables. The difficulty is: We reach the shaping code lots of times for
> every relayout or web font arriving. So initially, we may shape with a
> fallback font before the web font arrives, which affects the measurement
> result. Measuring in shaping is not synchronized with a stable layout stage
> or something like a "done" state of the page. So we could get to an
> approximation, but in shaping we can't currently determine what's the last
> state that "stayed" and was perceived by the user.
>
> David wrote:
>
>> So if it makes sense to add use counters to understand the compatibility
>> implications here, I think it may be worth adding what we would need to
>> understand the breakdown of how many sites are using this in a way that (a)
>> is interoperable across browsers/machines versus (b) is broken in some
>> browsers and working on others versus (c) is broken on some machines and
>> working on other machines, even using the same browser.  I suspect this
>> would mean something like measuring how often we see font-variant-position
>> used with a system font versus a downloadable font.  (This might also need
>> to be recorded along with the data on whether the font has or lacks the
>> superscript/subscript glyphs, because the intersection of the two might be
>> interesting.)
>
>
> I do agree this feature is most meaningful in combination with web fonts.
> Or even more specifically: Selecting font-variant-position needs to be
> carefully synced with the selected font and making sure the exact font has
> high chances of getting loaded.
> Do I understand correctly you suggest measuring font-variant-position
> usage with system fonts vs. web fonts because of the differences between
> machines? Or did you also mean platforms?
> The system font set used from the web is relatively stable between
> machines, meaning: Windows fonts are usually similar across machines (when
> it comes to those selected from the web), so are Mac fonts.
>
> In any event, I did a quick check:
> Mac: Helvetica, Times, and Courier New on Mac, and as far as I can tell,
> neither has a specific superscript or subscript OpenType or AAT font
> 

[blink-dev] Re: PSA: Virtual web test suits now have expiration dates

['Weizhong Xia' via blink-dev]

Hi Folks

This is a reminder as we are approaching July 1st, 2023, the initial
expiration date I set for all the virtual test suites. I did a search just
now. Most VTS would still expire at that date (161 out of 194).

Can we review this to make sure we do not lose coverage suddenly?

thanks, Weizhong

On Tue, Nov 22, 2022 at 12:07 PM Weizhong Xia  wrote:

> Hi Folks
>
> TL;DR: We now support expiration dates for virtual test suites. All
> virtual test suites now have an initial expiration date of July 1st, 2023.
> If you own any virtual test suites, please review this value, and update
> that to an appropriate date.
>
>  In the past we have seen cases where virtual test suites are left running
> when they should be deleted. By adding expiration dates, developers now
> have a chance to review the test suites based on latest status. The
> expiration date can be set to 'never' if necessary. An explanation is
> required for such a case.
>
> I will resent this a couple of times in case some people should miss this
> due to the holiday season.
>
> And happy holidays!
>
> thanks, Weizhong
>
>

-- 
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/CADXrSir%2Biz%2BgNqkLsVQQDEhKQH2TnuX-u4OVNjYSZz6yNpEu-w%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: CSS font-variant-position property

['Dominik Röttsches' via blink-dev]

Hi David and Rick,

It's a shame to me to be holding back interop on the case of fonts having
> the superscript or subscript glyphs out of fear for the case where they
> don't. Perhaps we can treat the case of font-variant-position being used
> with fonts that lack the glyphs as a site bug that we can work to address
> independently? Personally, as long as Safari and Chrome behave the same
> here, I'm skeptical that the lack of synthesis would turn into a
> non-trivial problem in practice.


I think expectations as to what should the browser do vs. what is
reasonably expected of site owners in terms of font selection and visual
delivery is on a spectrum (font fallback being a similar case).
In the case of using font-variant-position, I tend to agree with Rick: I'd
consider using font-variant-position without a suitable font is a site bug.
Safari seems to be of the same opinion by shipping font-variant-position
without synthesis.

If we were to ship without synthesis, would it be practical to have a
> UseCounter which measures how often we see font-variant-position used with
> a font that lacks the glyphs? This would tell us how important the bug is.
> If it remains really rare, then IMHO we've probably already wasted more
> energy worrying about it than it's worth. If it becomes more common over
> time then I think we have a variety of options, chiefly implementing
> synthesis, but also raising awareness with devtools features, UKM-based
> site-specific outreach, and possibly even interventions of some form (like
> using a fallback font?).


It's difficult to measure the visual end result accurately:
Only at shaping time we know exactly which font binary is used. This in
HarfBuzzShaper and we can determine whether the `sups` and `subs` OpenType
features

are
requested (we would need extra code for determining whether these features
were requested through font-variant-position: or font-feature-settings).
Then we can determine whether the font has such a feature in its shaping
tables. The difficulty is: We reach the shaping code lots of times for
every relayout or web font arriving. So initially, we may shape with a
fallback font before the web font arrives, which affects the measurement
result. Measuring in shaping is not synchronized with a stable layout stage
or something like a "done" state of the page. So we could get to an
approximation, but in shaping we can't currently determine what's the last
state that "stayed" and was perceived by the user.

David wrote:

> So if it makes sense to add use counters to understand the compatibility
> implications here, I think it may be worth adding what we would need to
> understand the breakdown of how many sites are using this in a way that (a)
> is interoperable across browsers/machines versus (b) is broken in some
> browsers and working on others versus (c) is broken on some machines and
> working on other machines, even using the same browser.  I suspect this
> would mean something like measuring how often we see font-variant-position
> used with a system font versus a downloadable font.  (This might also need
> to be recorded along with the data on whether the font has or lacks the
> superscript/subscript glyphs, because the intersection of the two might be
> interesting.)


I do agree this feature is most meaningful in combination with web fonts.
Or even more specifically: Selecting font-variant-position needs to be
carefully synced with the selected font and making sure the exact font has
high chances of getting loaded.
Do I understand correctly you suggest measuring font-variant-position usage
with system fonts vs. web fonts because of the differences between
machines? Or did you also mean platforms?
The system font set used from the web is relatively stable between
machines, meaning: Windows fonts are usually similar across machines (when
it comes to those selected from the web), so are Mac fonts.

In any event, I did a quick check:
Mac: Helvetica, Times, and Courier New on Mac, and as far as I can tell,
neither has a specific superscript or subscript OpenType or AAT font
feature.
Windows: Out of Arial, Courier, Times, Verdana only Verdana has subscript
glyphs (no superscript), the others do not have such a feature.

Bottom line:
I am with Rick on shipping this and considering a lack of glyph support up
a site bug.
Depending on feedback from API owners, if needed, we can measure an
approximation of selection of the feature vs. support in the font.

As is, this measurement may read too high (see above: initial shaping with
fallback font), but potentially we can filter that measurement and only
report selection of the feature vs. support in a successfully loaded
web-font. Development of such a measurement takes from 2 days to 9 days,
depending on complexity (very basic, no distinction of
font-feature-settings and font-variant-position, no distinction of system
fonts to complex: 

Re: [blink-dev] Intent to Ship: Partitioning Storage, Service Workers, and Communication APIs

[Mike Taylor]

OK - let's consider this I2S officially revived. Looking for a 3rd LGTM 
to begin shipping in M115.


We have implemented 3rd party deprecation trial support for M115+ (see 
https://developer.chrome.com/blog/storage-partitioning-deprecation-trial/#participate-in-the-deprecation-trials), 
and extended the deprecation trial's expiration date accordingly to 
account for the delay. And we have the Enterprise policy ready to go.


The rollout schedule will look something like the following, pending 
metrics and compatibility stability:


July 25th: 1% of Stable population (approximately 1 week after M115 is 
released)

Aug 8th: 10%
Aug 22nd: 50%
Sep 5: 100%

As always, if we discover significant user-facing breakage we'll explore 
pausing or rolling back to address.


thanks,
Mike

On 5/1/23 10:43 AM, Mike Taylor wrote:


Thanks Rick and Yoav.

We learned from two partners (one internal, one external) late last 
week that a 3P deprecation trial would be needed for them to preserve 
widely-used functionality while they work on a migration strategy.


We're tracking the work in crbug.com/1441411 and hope to have that 
ready by M115. Once we land the fix, I'll circle back and look for a 
3rd LGTM and have an updated rollout schedule. :)


On 5/1/23 12:21 AM, Yoav Weiss wrote:

LGTM2

On Thu, Apr 27, 2023, 16:23 Rick Byers  wrote:



On Wed, Apr 26, 2023 at 2:02 PM Mike Taylor
 wrote:

On 4/26/23 9:36 AM, Mike Taylor wrote:

> On 4/25/23 12:00 PM, Rick Byers wrote:
>
>> In terms of the standards / process piece, it looks as if
the spec
>> PRs have all stalled for several months. What do you think is
>> necessary to get these unblocked and landed? As the last
engine to
>> implement this behavior, perhaps we shouldn't feel too
compelled to
>> block shipping on PRs landing?

I was gently reminded offline that I didn't answer this part
of your
question - oops.

Right now it seems to me that the costs of landing these spec
PRs is
higher than we're willing to block on, given the requested
refactoring
(and yes, it's unfortunate that 3 engines would be shipping
essentially
unspecced behavior, but that's where we're at). That said,
I'm happy to
devote my few IC hours to pushing these along as a personal
project over
the coming months.


Thanks Mike. I trust your and wanderview@'s judgement here - I
know how hard y'all have been willing to work in the past to get
the right thing done in specs. Thanks for being willing to keep
pushing in parallel. But given two other implementations have
already shipped this, it was clearly already a spec bug that the
spec didn't reflect reality. I agree that we shouldn't block
shipping a 3rd implementation on spec refactoring work.

LGTM1 to ship from my perspective. Obviously this will need a
very thoughtful and careful roll-out. But I trust Mike and his
team to engage with impacted folks to make sure it goes smoothly,
as they did with UA reduction.



--
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/bc52292b-9142-adad-d126-b93231468ed0%40chromium.org.

Re: [blink-dev] Intent to Ship: First-party sets

[Chris Fredrickson]

Hi Andrey,

We're still collecting metrics at 1%. We want to be sure that this feature 
does not regress core web vitals , which is why 
we're taking our time and analyzing thoroughly. I will post here when we 
roll out to 100% (which I expect to be soon, within the next week or so -- 
if all continues to go well).

On Tuesday, May 30, 2023 at 8:57:20 AM UTC-4 Andrey Lipattsev wrote:

> How far along is this now? Are we at 100%?
>
> On Wednesday, 17 May 2023 at 21:11:35 UTC+2 Chris Fredrickson wrote:
>
>> Thanks all. Just an update - we're rolling First-Party Sets out to 1% on 
>> Chrome M113 Stable now, and plan to ramp up to 100% over the next few weeks 
>> (barring metrics regressions). 
>>
>> On Friday, April 7, 2023 at 12:45:41 PM UTC-4 Mike Taylor wrote:
>>
>>> After re-reading the spec, explainer, related discussions, and related 
>>> prior art over the past week or so, I believe that First Party Sets solves 
>>> important use cases, especially in a post-third-party cookie world. 
>>>
>>> LGTM3.
>>> On 4/7/23 11:36 AM, Yoav Weiss wrote:
>>>
>> Given the above, LGTM2
>>>
>>> On Wed, Apr 5, 2023 at 5:57 PM Alex Russell  
>>> wrote:
>>>
>>> Per today's OWNERS meeting, Daniel raised the point that we need a place 
 to approve/dispose the overall FPS direction rather than the smaller point 
 features, so for that reason I'm going to LGTM1 this here (contra Yoav's 
 previous message). 

 Best,

 Alex

 On Friday, March 31, 2023 at 8:31:10 AM UTC-7 Chris Harrelson wrote:

>>> Hi Martin,
>
> On Fri, Mar 31, 2023 at 12:32 AM Martin Thomson  
> wrote:
>
>> As long as FPS affects how the web operates in any way, it should be 
>> subject to standardization and - I would expect - the same review as any 
>> other feature.
>>
>
> With the plan Yoav is suggesting, the Blink API owners would still 
> review it carefully, but in the context of the other intents that involve 
> web-exposed behavior. In the end, which email we reply to is a 
> technicality; either way, we'll review the entire feature set.
>
> On Wed, Mar 29, 2023 at 6:44 PM Yoav Weiss  
>> wrote:
>>
> Thanks for filing this intent. I agree with your analysis that it's 
>>> not directly web-exposed, and as such, I don't think LGTMs are required 
>>> (but still appreciate the intent as required context for rSA and rSAF). 
>>> We'll see if other API owners disagree.
>>>
>>> On Mon, Mar 20, 2023 at 10:31 PM Johann Hofmann <
>>> joha...@chromium.org> wrote:
>>>
>> Contact emails 

 cfre...@chromium.org, shu...@chromium.org, kaust...@chromium.org, 
 joha...@chromium.org

>>>
 Explainer 

 https://github.com/WICG/first-party-sets

 Specification 

 https://wicg.github.io/first-party-sets

 Design docs 

 First-Party Sets: Initial prototype description 
 

 First-Party Sets Prototype Design Doc 
 

 Summary 

 First-Party Sets (“FPS”) provides a framework for developers to 
 declare relationships among sites, to enable limited cross-site cookie 
 access for specific, user-facing purposes. This is facilitated through 
 the 
 use of the Storage Access API 
  and 
 requestStorageAccessFor 
  API.

 The First-Party Sets proposal that we intend to ship significantly 
 differs from its originally proposed design, as we have incorporated 
 feedback from various stakeholders. An overview of what changed and 
 why can 
 be found here 
 
 .

 It’s important to note that because of its integration with the 
 Storage Access API and requestStorageAccessFor, FPS is not a feature 
 that 
 is directly web-exposed. We still consider its overall impact on the 
 web 
 platform to be big enough to follow the blink launch process.

 We have submitted adjacent Intents to Ship both 
 requestStorageAccess and requestStorageAccessFor.


 Blink component 

 Privacy 
 

 TAG review 

 https://github.com/w3ctag/design-reviews/issues/342

 TAG review status 

 Pending

Re: [blink-dev] Intent to Ship: First-party sets

['Andrey Lipattsev' via blink-dev]

How far along is this now? Are we at 100%?

On Wednesday, 17 May 2023 at 21:11:35 UTC+2 Chris Fredrickson wrote:

> Thanks all. Just an update - we're rolling First-Party Sets out to 1% on 
> Chrome M113 Stable now, and plan to ramp up to 100% over the next few weeks 
> (barring metrics regressions). 
>
> On Friday, April 7, 2023 at 12:45:41 PM UTC-4 Mike Taylor wrote:
>
>> After re-reading the spec, explainer, related discussions, and related 
>> prior art over the past week or so, I believe that First Party Sets solves 
>> important use cases, especially in a post-third-party cookie world. 
>>
>> LGTM3.
>> On 4/7/23 11:36 AM, Yoav Weiss wrote:
>>
> Given the above, LGTM2
>>
>> On Wed, Apr 5, 2023 at 5:57 PM Alex Russell  
>> wrote:
>>
>> Per today's OWNERS meeting, Daniel raised the point that we need a place 
>>> to approve/dispose the overall FPS direction rather than the smaller point 
>>> features, so for that reason I'm going to LGTM1 this here (contra Yoav's 
>>> previous message). 
>>>
>>> Best,
>>>
>>> Alex
>>>
>>> On Friday, March 31, 2023 at 8:31:10 AM UTC-7 Chris Harrelson wrote:
>>>
>> Hi Martin,

 On Fri, Mar 31, 2023 at 12:32 AM Martin Thomson  
 wrote:

> As long as FPS affects how the web operates in any way, it should be 
> subject to standardization and - I would expect - the same review as any 
> other feature.
>

 With the plan Yoav is suggesting, the Blink API owners would still 
 review it carefully, but in the context of the other intents that involve 
 web-exposed behavior. In the end, which email we reply to is a 
 technicality; either way, we'll review the entire feature set.

 On Wed, Mar 29, 2023 at 6:44 PM Yoav Weiss  
> wrote:
>
 Thanks for filing this intent. I agree with your analysis that it's not 
>> directly web-exposed, and as such, I don't think LGTMs are required (but 
>> still appreciate the intent as required context for rSA and rSAF). 
>> We'll see if other API owners disagree.
>>
>> On Mon, Mar 20, 2023 at 10:31 PM Johann Hofmann  
>> wrote:
>>
> Contact emails 
>>>
>>> cfre...@chromium.org, shu...@chromium.org, kaust...@chromium.org, 
>>> joha...@chromium.org
>>>
>>> Explainer 
>>>
>>> https://github.com/WICG/first-party-sets
>>>
>>> Specification 
>>>
>>> https://wicg.github.io/first-party-sets
>>>
>>> Design docs 
>>>
>>> First-Party Sets: Initial prototype description 
>>> 
>>>
>>> First-Party Sets Prototype Design Doc 
>>> 
>>>
>>> Summary 
>>>
>>> First-Party Sets (“FPS”) provides a framework for developers to 
>>> declare relationships among sites, to enable limited cross-site cookie 
>>> access for specific, user-facing purposes. This is facilitated through 
>>> the 
>>> use of the Storage Access API 
>>>  and 
>>> requestStorageAccessFor 
>>>  API.
>>>
>>> The First-Party Sets proposal that we intend to ship significantly 
>>> differs from its originally proposed design, as we have incorporated 
>>> feedback from various stakeholders. An overview of what changed and why 
>>> can 
>>> be found here 
>>> 
>>> .
>>>
>>> It’s important to note that because of its integration with the 
>>> Storage Access API and requestStorageAccessFor, FPS is not a feature 
>>> that 
>>> is directly web-exposed. We still consider its overall impact on the 
>>> web 
>>> platform to be big enough to follow the blink launch process.
>>>
>>> We have submitted adjacent Intents to Ship both requestStorageAccess 
>>> and requestStorageAccessFor.
>>>
>>>
>>> Blink component 
>>>
>>> Privacy 
>>> 
>>>
>>> TAG review 
>>>
>>> https://github.com/w3ctag/design-reviews/issues/342
>>>
>>> TAG review status 
>>>
>>> Pending
>>>
>>> Risks 
>>>
>>> Interoperability and Compatibility 
>>>
>>> This is not a breaking change. To use it, sites will need to opt in 
>>> to using First-Party Sets. There is no change to existing behavior for 
>>> sites not opting in to First-Party Sets.
>>>
>>>
>>> Gecko: Negative (
>>> https://github.com/mozilla/standards-positions/issues/350)
>>>
>>> WebKit: Negative (
>>> https://github.com/WebKit/standards-positions/issues/93)
>>>
>>> Web developers: Positive. FPS has been extensively discussed 

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