[blink-dev] Intent to Ship: RTCRtpSender setParameters() extensions for requesting the generation of a key frame

['Philipp Hancke' via blink-dev]

Contact emails

phan...@microsoft.com, ma...@microsoft.com

Explainer

https://fippo.github.io/webrtc-explainers/rtcrtpsender-setparameters

Specification

https://w3c.github.io/webrtc-extensions/#rtcrtpsender-setparameters-keyframe

Summary

Adds an optional second parameter to WebRTC's RTCRtpSender.setParameters
call which can be used to ask the associated encoder to generate a key
frame.

Blink component

Blink>WebRTC>PeerConnection


TAG review

None, small addition to WebRTC

TAG review status

Not applicable

RisksInteroperability and Compatibility

None

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/858)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/237)

Web developers: Positive Microsoft Teams is quite interested in the feature.

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


Debuggability

None

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

Yes

Is this feature fully tested by web-platform-tests

?

Yes

See WPT added as part of
https://chromium-review.googlesource.com/c/chromium/src/+/4643591

Flag name on chrome://flags

None

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Tracking bug

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

Estimated milestones

Shipping on desktop

122


Anticipated spec changes

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5161082937409536

This intent message was generated by Chrome Platform Status
 and then copy-pasted around

-- 
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/CADxkKiJ0%3D-O%2BQoJoXfEWO1KBrLNHWnzTUGxXJSJOpm8BJTQEjw%40mail.gmail.com.

[blink-dev] Re: PSA: depot_tools migrated to python 3.11

['Josip Sokcevic' via infra-announce]

Hi all,

Shortly after this email, we hit a few problems and the change was rolled
back. We did a few relands since, and today's reland looks good.

If you encounter any issues please file a bug.

Best,

Josip Sokcevic

On Tue, Dec 12, 2023, 16:11 Josip Sokcevic  wrote:

> Hi all,
>
> depot_tools vpython3 is upgraded to 3.11 (cl ).
> No action is required on your end.
>
> We have fixed several incompatibilities prior to upgrade and don't
> anticipate any issues with the upgrade. However, if you encounter any
> problems, file a bug under the Infra>SDK
> 
> component.
>
> Thanks,
>
> Josip
>

-- 
You received this message because you are subscribed to the Google Groups 
"infra-announce" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to infra-announce+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/infra-announce/CAJiyOigmfiA21Z8D58z-_0C%3DbKc%2BfexGh19C4Hh8VWTLtuiG%2BQ%40mail.gmail.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/CAJiyOigmfiA21Z8D58z-_0C%3DbKc%2BfexGh19C4Hh8VWTLtuiG%2BQ%40mail.gmail.com.

Re: [blink-dev] Intent to Deprecate: non-standard `shadowroot` attribute for declarative shadow DOM

[Mason Freed]

Closing the loop - the old `shadowroot` attribute was successfully removed 
from Blink over M119/M120. It's now fully disabled everywhere. No bugs were 
reported.

Thanks,
Mason


On Tuesday, October 24, 2023 at 8:50:00 AM UTC-7 Mason Freed wrote:

> Hearing no objections, I'm moving forward with this feature removal 
> starting in M119.
>
> Thanks,
> Mason
>
>
> On Tuesday, October 10, 2023 at 6:55:59 PM UTC-7 Mason Freed wrote:
>
>> Checking back in on this deprecation thread. The use counter for the 
>> deprecated shadowroot attribute 
>>  has 
>> plateaued at about 0.045% of page loads. I have had the feature disabled 
>> for 50% of Canary, Dev, and Beta since July, and I have received exactly 
>> zero bug reports. Based on that, plus my strong belief that any existing 
>> usage must be use-counted or it would already be broken in all other 
>> browsers, I'd like to attempt to slowly disable the feature, via Finch, 
>> starting in 119. My plan would be to move to 1% of stable when 119 is 
>> released, holding for several weeks to monitor for breakage. If none is 
>> reported, I'll move to 2% for another week, etc. Any objections?
>>
>> Thanks,
>> Mason
>>
>>
>> On Monday, August 14, 2023 at 4:09:24 PM UTC-7 Mason Freed wrote:
>>
>>> I'm checking back in on this deprecation thread. In the intervening 5 
>>> milestones, the use counter for the deprecated attribute 
>>>  has 
>>> unfortunately increased, rather than decreased. The old attribute is seen 
>>> on 0.025% of page loads, just slightly more than the new shadowrootmode 
>>> attribute 
>>>  which 
>>> is at 0.02%. I'm adding a UKM to look into which sites are the culprits, 
>>> but I'd also like to start Finch-disabling the feature for a portion of 
>>> Canary/Dev and maybe Beta users, to suss out problems and improve 
>>> visibility of this deprecation to site owners. We're now about 3 months out 
>>> from 119 (the target removal milestone) going to stable. Any objections?
>>>
>>> Thanks,
>>> Mason
>>>
>>>
>>> On Tuesday, February 21, 2023 at 1:36:25 PM UTC-8 Mason Freed wrote:
>>>
 On Sun, Feb 19, 2023 at 11:33 PM Yoav Weiss  
 wrote:

> That uptick may suggest a single large entity that started using this, 
> and may be easy to move to the new attribute.
> Have you tried turning the usecounter into a UKM 
> 
>  
> to try and see where the usage is coming from?
>

 Agreed, that uptick is likely a single party. My hope is that it will 
 go back down as that entity moves to the new attribute. Adding a UKM 
 sounds 
 like a reasonable idea - I'll do that if I don't see a down-trend in the 
 usecounter data soon.
  

> The other alternative is that some developer documentation is pointing 
> at the old attribute name. Can you verify that's not the case?
>

 Indeed that's very likely. Our own blog post 
  still describes the old 
 attribute. (I'm working on getting that updated.)
  

> Otherwise, we typically prefer to have deprecation messages with clear 
> milestones for their removal date. It seems to me that a year may be a 
> lot 
> for this. Would you be comfortable with setting the removal date for 6 
> milestones ahead? Maybe the UKM analysis can change our thinking here?
>

 I'm reasonably comfortable with targeting 6 milestones out. That'd be 
 roughly M118 as the last version that supports the old `shadowroot` 
 attribute, and M119 as the first that doesn't. And closer to the deadline 
 we can re-evaluate usage and make sure it's low enough for comfort. Does 
 that sound reasonable? If so, I'll update the documentation and console 
 messages accordingly.

 Thanks,
 Mason

  

>
> On Fri, Feb 17, 2023 at 6:38 PM Mason Freed  
> wrote:
>
>>
>> On Thu, Feb 16, 2023 at 5:19 PM Jason Robbins  
>> wrote:
>>
>>> On Wednesday, February 15, 2023 at 10:14:48 PM UTC-8 
>>> yoav...@chromium.org wrote:
>>> +Jason Robbins - FYI, this didn't make it to the chromestatus tool.
>>>
>>> I have an idea about what went wrong.
>>>
>>> "Intent to deprecate" is the subject line that is expected for the 
>>> first stage in the deprecation process.  It was detected as such, but 
>>> that 
>>> stage does not require any review.Based on this thread and the 
>>> contents 
>>> of the feature entry it looks like the final stage was what needed to 
>>> be 
>>> reviewed.
>>>
>>
>> Sorry - 

Re: [blink-dev] Intent to Ship: PointerEvent.deviceId for Mult-Pen Inking

['Sahir Vellani' via blink-dev]

Hi all, good news!

Reviving this thread because we have accomplished:
1. TAG Review Completion:  Extending the PointerEvent with Unique DeviceId 
Attribute · Issue #880 · w3ctag/design-reviews (github.com) 
 Resolution: Satisfied
2. WICG Repository for standardization discussions. Link to explainer in 
WICG Repo:  pointer-event-extensions/pointer-event-device-id-explainer.md 
at main · WICG/pointer-event-extensions (github.com) 

3. A PR against the PointerEvent spec with proposed changes:  Add deviceId 
to PointerEvent spec by sahirv · Pull Request #495 · w3c/pointerevents 
(github.com)  We will 
be waiting for Spec Level 3 to come out before this can be merged; but this 
provides an official starting point for the standardized description of 
this feature. Based on the feedback received, I don't anticipate any major 
changes to the design.

Reviewers, can we please get another review for shipping this feature?
On Wednesday, October 18, 2023 at 8:55:43 AM UTC-7 sligh...@chromium.org 
wrote:

> I agree that this needs a spec PR and the explainer should at least 
> migrate to WICG before we agree to ship. Also, can you please link to the 
> TAG review?
>
> Best,
>
> Alex
>
> On Tuesday, October 17, 2023 at 4:16:41 AM UTC-7 Yoav Weiss wrote:
>
>> On Tue, Oct 17, 2023 at 12:42 AM Mike Taylor  
>> wrote:
>>
>>> LGTM1
>>> On 10/15/23 11:07 AM, 'Sahir Vellani' via blink-dev wrote:
>>>
>>> Thanks for the feedback, I wasn't aware they were mandatory. The steps 
>>> have been started, just awaiting feedback from Security and Privacy 
>>> reviewers. I've received LGTMs for all other areas. After our response to 
>>> WebKit's question, they did not have any further follow-up questions. So 
>>> I'm assuming all is well.
>>>
>>> On Wednesday, October 11, 2023 at 4:59:15 AM UTC-7 Daniel Bratell wrote:
>>>
 I see that various mandatory steps in chromestatus 
 (privacy,security,enterprise,debuggability,testing) seems to be unstarted. 
 It is possible they were made mandatory after you create the entry, but it 
 would be good if you could get them started now at least.

 Also, it's unfortunate that TAG and standards positions requests have 
 not resulted in anything, but that is hardly your fault. There were some 
 questions in the WebKit request. Is all that ok now?

 /Daniel
 On 2023-10-06 20:10, 'Sahir Vellani' via blink-dev wrote:



 On Friday, October 6, 2023 at 9:03:35 AM UTC-7 mike...@chromium.org 
 wrote:


 On 10/4/23 7:43 PM, 'Sahir Vellani' via blink-dev wrote:

 Contact emails 
 gerc...@microsoft.com, sahir@microsoft.com

 Explainer 

 https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/PointerEventDeviceId/explainer.md

 Specification 

 https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/PointerEventDeviceId/explainer.md


>> Is there a more formal spec for this?
>> Any support outside of Microsoft that would enable y'all to move this to 
>> the WICG?
>>  
>>
>>>

 Summary 

 As devices with advanced pen input capabilities are becoming 
 increasingly prevalent, it is important that the web platform continues to 
 evolve to fully support these advanced features in order to unlock rich 
 experiences for both end users and developers. One such advancement is the 
 ability for a device's digitizer to recognize more than one pen device 
 interacting with it simultaneously. This feature is an extension to the 
 PointerEvent interface to include a new attribute, deviceId, that 
 represents a session-persistent, document isolated, unique identifier that 
 a developer can reliably use to identify individual pens interacting with 
 the page.


 Blink component 
 Blink>Input 
 

 TAG review 
 https://github.com/w3ctag/design-reviews/issues/880

 TAG review status 
 Pending. TAG review has been pending for 2 months.

 Risks 


 Interoperability and Compatibility 


 *Gecko*: No signal (
 https://github.com/mozilla/standards-positions/issues/715)

 *WebKit*: No signal (
 https://github.com/WebKit/standards-positions/issues/102)

 *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?*

 None


 Debuggability 


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

Re: [blink-dev] Intent to Ship: Protected Audiences Negative Targeting

[Rick Byers]

LGTM3

On Wed, Jan 3, 2024 at 6:44 PM Mike Taylor  wrote:

> No concerns. LGTM2
> On 1/3/24 1:41 PM, Chris Harrelson wrote:
>
> LGTM1
>
> On Wed, Jan 3, 2024 at 5:05 AM Orr Bernstein  wrote:
>
>> Hi all,
>>
>> Thank you for your guidance here. I've updated the chromestatus entry to
>> reflect the aforementioned delta, noting that the HTTP response header
>> processing involved in this feature will work for both Fetch and iframe
>> navigations. Both the explainer (
>> https://github.com/WICG/turtledove/pull/887) and spec (
>> https://github.com/WICG/turtledove/pull/918) changes to reflect that
>> delta have been merged. When you have a chance, could you please take a
>> look? Thank you again!
>>
>> All the best,
>> - Orr
>>
>> On Wednesday, November 8, 2023 at 3:13:36 PM UTC-5 Chris Harrelson wrote:
>>
>>> If you want to batch it together that sounds fine to me. Can you:
>>>
>>> * Update the chromestatus entry
>>>  accordingly
>>> (including shipping milestones, updated description, and
>>> potentially re-review of privacy security etc)
>>> * Land those two PRs for the spec and explainer
>>>
>>> Then the API owners can review again and re-issue 3 new LGTMs if it
>>> looks good.
>>>
>>> On Wed, Nov 8, 2023 at 11:47 AM 'Orr Bernstein' via blink-dev <
>>> blin...@chromium.org> wrote:
>>>
 Hi Chris,

 Thanks so much for the quick response. We have not yet shipped the
 negative targeting work. The absence of these additional changes means that
 some of the potential adopters of negative targeting can't do so, and so I
 was indeed proposing to batch these additional changes together with
 negative targeting. Would you recommend a new I2S and chromestatus entry?
 Thanks again.

 All the best,
 - Orr


 On Wednesday, November 8, 2023 at 1:37:19 PM UTC-5 Chris Harrelson
 wrote:

> Hi Orr,
>
> Have you already shipped the negative targeting work? Or are you
> proposing to batch these additional changes together with that, and
> consider these new changes thematically related? If not, I think it would
> be more clear to make a new I2S and chromestatus entry.
>
> On Wed, Nov 8, 2023 at 9:58 AM 'Orr Bernstein' via blink-dev <
> blin...@chromium.org> wrote:
>
>> Hi all,
>>
>> We have a small delta to this feature we'd like to implement. In our
>> current design, ad techs need to provide a flag, `adAuctionHeaders` on
>> their `fetch()` request. (
>> https://github.com/WICG/turtledove/blob/main/FLEDGE.md#63-http-response-headers)
>> However, we received feedback that some ad techs use iframe navigation
>> instead of a `fetch()`.   (
>> https://github.com/WICG/turtledove/issues/319#issuecomment-1766815150)
>> To enable those ad techs to use this feature, we'd like to minimally 
>> extend
>> our design to allow those that use iframe navigation to specify an
>> `adAuctionHeaders` attribute on the iframe element that behaves the same 
>> as
>> the `adAuctionHeaders` flag on `fetch()` requests.
>>
>> For more details, please see the PRs we've prepared for the spec -
>> https://github.com/WICG/turtledove/pull/883 - and the explainer -
>> https://github.com/WICG/turtledove/pull/887.
>>
>> Could you please review and provide LGTMs to ship this delta? Thank
>> you so much!
>>
>> All the best,
>> - Orr
>>
>> On Friday, October 20, 2023 at 12:06:12 PM UTC-4 Orr Bernstein wrote:
>>
>>> FYI, the spec (https://github.com/WICG/turtledove/pull/796) has
>>> been merged. Thank you all again.
>>>
>>> All the best,
>>> - Orr
>>>
>>> On Wednesday, October 4, 2023 at 3:04:23 PM UTC-4 Orr Bernstein
>>> wrote:
>>>
 Thank you all so much. I'll update this thread when
 https://github.com/WICG/turtledove/pull/796 has landed.

 All the best,
 - Orr


 On Wed, Oct 4, 2023 at 11:51 AM Chris Harrelson <
 chri...@chromium.org> wrote:

> LGTM3, same.
>
> On Wed, Oct 4, 2023 at 8:50 AM Yoav Weiss 
> wrote:
>
>> LGTM2 with the same conditions
>>
>> On Monday, October 2, 2023 at 11:00:07 PM UTC+2 Mike Taylor wrote:
>>
>>> LGTM1 % landing https://github.com/WICG/turtledove/pull/796.
>>> Please follow up with the WPTs as well.
>>> On 9/27/23 11:56 AM, Chris Harrelson wrote:
>>>
>>> Please fill out the other chromestatus review categories
>>> (privacy, security, etc); we'll re-review once those are done.
>>>
>>> On Wed, Sep 20, 2023 at 2:42 PM 'Orr Bernstein' via blink-dev <
>>> blin...@chromium.org> wrote:
>>>
 Contact emails

 or...@google.com, paulj...@chromium.org

 

[blink-dev] [PSA] python 2 removed from depot_tools, vpython still available

['Josip Sokcevic' via infra-announce]

Hi all,

depot_tools no longer bootstraps python2. For Windows, this means that
python and python.bat will no longer be available in depot_tools root path.
vpython continues to work, but we plan to remove it eventually.

CL: https://crrev.com/c/5170265
Bug: https://crbug.com/1376538

If you encounter any problems, please file a bug under Infra>SDK.

Best,

-- 
Josip Sokcevic

-- 
You received this message because you are subscribed to the Google Groups 
"infra-announce" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to infra-announce+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/infra-announce/CAJiyOii9p4v1r11H3888f0KD4O5MfbpQ2oT3aC4-9BUQ1U3QAg%40mail.gmail.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/CAJiyOii9p4v1r11H3888f0KD4O5MfbpQ2oT3aC4-9BUQ1U3QAg%40mail.gmail.com.

[blink-dev] PSA: FedCM will skip well-known file checks when the IDP and RP are same-site

[Christian Biesinger]

The FedCM  code
has previously enforced that an Identity Provider (IDP)’s configURL is
listed in .well-known/web-identity under their eTLD+1 (e.g.
https://google.com/.well-known/web-identity) so that the IDP can not encode
RP data in the accounts endpoint URL.

However, sometimes the RP and IDP are under the same eTLD+1 in staging or
testing setups. The staging IDP’s URL can not be listed in the well-known
file because it can only contain one URL. At the same time, cookies can
already be shared among hosts in the same eTLD+1 with the Domain attribute,
so this check has no impact on privacy for this case.

We have therefore changed Chrome to skip the well-known check if the RP and
IDP are in the same eTLD+1. The change has been approved by the Chrome Web
Platform security and privacy teams and will ship in Chrome 122.

One example where this would help is
https://github.com/GoogleChromeLabs/privacy-sandbox-dev-support/issues/189
– the issue has been closed because an existing flag has been deemed
sufficient after a bug fix, but with this change no flag is needed.

-- 
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/CAPTJ0XGtu88LK7UzWPw1gyNCnZaZhdovdeqzu4uay1vvpNp%3DnQ%40mail.gmail.com.

[blink-dev] Web-Facing Change PSA: Speculation rules: infer "source" if possible

[Jeremy Roman]

Contact emailsjbro...@chromium.org

Specification
https://wicg.github.io/nav-speculation/speculation-rules.html#parse-a-speculation-rule

Summary

This allows speculation rules to be written more concisely if the type of
the rule is not ambiguous (i.e., most cases). For example:
{"source":"list","urls":["https://example.com/"]} can be written {"urls":["
https://example.com/"]} and
{"source":"document","where":{"selector_matches":"#nav > a"}} can be
written {"where":{"selector_matches":"#nav > a"}} Existing rules (with
explicit "source") continue to work with no change. See
https://github.com/WICG/nav-speculation/pull/295.


Blink componentInternals>Preload


TAG reviewNone

TAG review statusNot applicable

Risks


Interoperability and Compatibility

This is fully backward compatible.


*Gecko*: No signal

*WebKit*: No signal

*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?

None


Debuggability

covered by existing developer tools


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

Is this feature fully tested by web-platform-tests

?Yes

Flag name on chrome://flagsNone

Finch feature nameSpeculationRulesImplicitSource

Requires code in //chrome?False

Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1517696

Estimated milestones
Shipping on desktop 122
Shipping on Android 122
Shipping on WebView 122

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

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

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/CACuR13dmORajN-tr7EhU6XcjbTdXt6_WcWSiuskezZVbB9fN7w%40mail.gmail.com.

Re: [blink-dev] Intent to Prototype and Ship: MessagePort.onclose

[Mike Taylor]

Thanks Rakina - right now the biggest blocker is the unlanded spec PR. 
Things should move pretty quickly once that's resolved.


On 1/10/24 11:15 PM, Rakina Zata Amni wrote:
> Hoping that the design doc can become an GH explainer with the usual 
format, as the design doc doesn't answer questions in the strucutre we 
like to see


Can you clarify which part isn't answered yet in the explainer 
? 



From the list in your link:

  * The user-facing problem which needs to be solved;
  o Covered by this section

.
  * The proposed approach to solving the problem;
  o Covered by this section

.
  * The way the proposed solution may be used in practice to address
the intended use cases, via example code;
  o Pretty much covered by this section


 although
there's no actual code example. We will add the code example
(basically just an event listener using the close event)
  * Any other venues (such as mailing list, pull requests or issue
threads external to the location of the explainer) where the
reader may catch up on discussions regarding the proposed feature
or features;
  o The issue  is
linked from the explainer.
  * The alternatives which have already been considered and why they
were not chosen;
  o Covered by this section

.
  * Accessibility, security and privacy implications which have been
considered as part of the design process.
  o Security & Privacy is covered by this sectio

n,
and there is no accessibility implication introduced by the
new event.


Please let us know if there are any parts that need further clarification.

(BTW just to update the thread, the TAG review 
 has been 
requested last month)


On Thu, Jan 4, 2024 at 1:49 AM Alex Russell  
wrote:


+1 to Yoav's excitement about this. Thank you for pushing it forward.

On TAG review, we're living in hope that the newly-expanded TAG
will have more bandwidth and focus for reviews, but as Mike says,
we're increasingly timing out. Filing for review at I2P time is
always the pro-move, and I it's a bad look for us to be leaving it
to late regardless.

Hoping that the design doc can become an GH explainer with the
usual format, as the design doc doesn't answer questions in the
strucutre we like to see:

https://w3ctag.org/explainers/

Best,

Alex

On Wednesday, December 13, 2023 at 8:46:20 AM UTC-8 Mike Taylor wrote:

Gentle reminder to request approvals for the other review
gates in chromestatus, thanks.

On 12/1/23 1:05 PM, Mike Taylor wrote:


On 11/30/23 10:56 PM, Fergal Daly wrote:


On Wednesday, November 29, 2023 at 2:23:12 PM UTC+9 Yoav
Weiss wrote:


On Tue, 28 Nov 2023 at 12:31, Nonoka Muraki
 wrote:
TAG review

Not needed because This is a small feature where we
just dispatch a new event.


Unfortunately that's not a criteria for skipping a TAG
review. Can you file one?


I'm concerned by this because every TAG review I've seen in
the last couple of years has taken months to get a response.
If our own privacy review is positive and we have agreement
with other vendors would we block on the TAG review?

In practice, we don't block on TAG reviews, but we like to
give them a chance to review or comment within a reasonable
time period (typically a week or two).




--
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/7f7a2d3c-876e-4fec-bd36-254846cb6261%40chromium.org.

Re: [blink-dev] Re: Intent to Ship: Close requests for CloseWatcher, , and popover=""

[Philip Jägenstedt]

Thanks for the update, Domenic, that sounds like a solid plan to me.
Keeping existing content working is important, and if one developer filed a
bug others have probably been affected too. Happily the spec fix doesn't
seem like it complicates things, either.

On Thu, Jan 11, 2024 at 3:23 AM Domenic Denicola 
wrote:

> Hi all,
>
> Over the holidays, some developers experienced the 0.15% of pages
> impacted by skipped cancel events on s, and filed a regression bug
> . Out of
> an abundance of caution, we disabled this feature remotely using Finch for
> M120 and M121, and then disabled it in the codebase for M122.
>
> In the subsequent discussions, we discovered two possible spec changes we
> could make to drive down that 0.15% even further:
>
>- A bug fix to allow cancel events to fire for the first-created close
>watcher, as long as it was created by user activation. Even if the user
>never interacts with the . Spec issue
>, spec PR
>, wip CL
>.
>- A more significant change, to consider firing cancel events even if
>you cannot call preventDefault(). Spec issue
>.
>
> Our plan is to implement the first of these bug fixes, which will address
> the cases reported on the Chromium bug tracker so far, and then re-enable
> the feature starting in M122.
>
> In parallel we'll explore fast-following with the second change, after a
> bit more discussion with the community. (The main goal of the second change
> is to enable a use case; we don't think the compat improvement is urgent.
> See more discussion on the spec issue.)
>
> Let me know if there are any concerns,
> -Domenic
>
> On Thu, Oct 19, 2023 at 12:59 AM Yoav Weiss 
> wrote:
>
>> LGTM3
>>
>> I agree that introspection can be additive on top of what we want to ship
>> here.
>>
>> On Wed, Oct 18, 2023 at 5:48 PM Philip Jägenstedt 
>> wrote:
>>
>>> The spec change has now landed, LGTM2.
>>>
>>> More introspection could possibly be useful
>>> , but
>>> without a concrete use case, example code, or developer feedback, I think
>>> it's hard to do a good job. Having reviewed the spec change, I'm confident
>>> that exposing more information is technically straightforward if the need
>>> arises.
>>>
>>> On Thu, Oct 12, 2023 at 1:59 AM Domenic Denicola 
>>> wrote:
>>>


 On Thu, Oct 12, 2023 at 12:51 AM Yoav Weiss 
 wrote:

>
>
> On Friday, October 6, 2023 at 12:34:21 AM UTC+2 Chris Harrelson wrote:
>
> Hi,
>
> While Alex's concerns are totally valid to consider from a feature
> design perspective, I think they are better to be discussed on the WHATWG
> issues for this feature. I chatted offline with Alex and he agreed about
> that point, and agreed to post comments and questions there.
>
> So from an API owners perspective LGTM1 modulo considering and taking
> into account all comments and feedback from Alex on the spec (as we should
> for all such feedback from anyone, of course!).
>
>
> On Wed, Oct 4, 2023 at 8:28 AM Domenic Denicola 
> wrote:
>
>
>
> 2023年10月4日(水) 8:16 Alex Russell :
>
>
>
> On Monday, October 2, 2023 at 10:16:53 AM UTC-7 Domenic Denicola wrote:
>
>
>
> 2023年10月2日(月) 10:11 Alex Russell :
>
>
>
> On Sunday, October 1, 2023 at 9:08:57 PM UTC-7 Domenic Denicola wrote:
>
> On Sat, Sep 30, 2023 at 5:01 AM Alex Russell 
> wrote:
>
> The implicit behaviours based on construction order in this API are
> very strange and seem like footguns.
>
>
> I don't understand why you find this strange, or a footgun. It's
> intended to be the opposite: it guides developers toward creating the
> experience the user expects, where when the user requests to close
> something, the last thing that was opened, is what closes.
>
>
> Chris Palmer covered this pretty well recently, so I'll defer to his
> more eloquent writeup:
>
> https://noncombatant.org/2023/05/29/complexities-of-allocation/
>
> Basically, this is spooky action at a distance and without _at least_
> some reflection and manipulation surface (via DOM, probably), it's hard to
> understand how this won't turn into a footgun.
>
> As a separate note, I'm disappointed in the proliferation of APIs that
> affect DOM but have no API and reflection. Import Maps spring to mind, but
> there are other recent examples too. If manual disposal is going to be
> required for this, we should at least make it possible to introspect
> outside the scope in which an object that defines this behaviour is