date:20240112

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

2024-01-12 Thread 'Harald Alvestrand' via blink-dev

This extension has consensus in the WEBRTC WG, and CLs are approved by the
Chrome WebRTC folks.


On Fri, Jan 12, 2024 at 8:01 AM 'Philipp Hancke' via blink-dev <
blink-dev@chromium.org> wrote:

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

-- 
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/CAOqqYVEd14tYEaUdAUCeQGDqEKEJ7EiR1ikENhy%2B5G9sLEu1dA%40mail.gmail.com.

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

2024-01-12 Thread Nonoka Muraki

spec PR was merged.(https://github.com/whatwg/html/pull/9933)

On Friday, January 12, 2024 at 12:41:31 AM UTC+9 Mike Taylor wrote:

> 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;
>- Covered by this section 
>   
> 
>   . 
>- The proposed approach to solving the problem;
>- Covered by this section 
>   
> 
>   . 
>- The way the proposed solution may be used in practice to address the 
>intended use cases, via example code;
>- 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;
>- The issue  is linked 
>   from the explainer. 
>- The alternatives which have already been considered and why they 
>were not chosen;
>- Covered by this section 
>   
> 
>   . 
>- Accessibility, security and privacy implications which have been 
>considered as part of the design process.
>- 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/c1d7e05e-0980-4146-a028-273269d14c1an%40chromium.org.

[blink-dev] Intent to Ship: Long Animation Frame Timing

2024-01-12 Thread Noam Rosenthal

Contact emailsnrosent...@chromium.org

Explainer
https://github.com/w3c/longtasks/blob/loaf-explainer/loaf-explainer.md

Specificationhttps://w3c.github.io/longtasks/


Summary

This is an extension of long tasks. It measures the task together with its
subsequent rendering update, adding information such as long running
scripts, rendering time, and time spent in forced layout and style ("layout
thrashing"). Developers can use this as a diagnostic for "sluggishness",
which is measured by INP, by finding the causes for main-thread congestion
which is often the cause for bad INP.


Blink componentBlink>PerformanceAPIs


TAG reviewhttps://github.com/w3ctag/design-reviews/issues/911

TAG review statusIssues addressed

Chromium Trial NameLongAnimationFrameTiming

Link to origin trial feedback summaryhttps://github.com/w3c/longtasks

Origin Trial documentation link
https://github.com/w3c/longtasks/blob/main/loaf-explainer.md

Risks


Interoperability and Compatibility



*Gecko*: Positive Not yet a formal signal but showed positive interest at
WG call.

*WebKit*: No signal

*Web developers*: Positive (
https://twitter.com/jebbacca/status/1653355406368952321) Wix, Taboola, and
others have already experimented with this in Canary. Strong excitement
from several partners at We Love Speed conference.

*Other signals*:

Ergonomics

It should work well with other performance timeline entries, mainly
event-timing/INP.


Security

This feature exposes rendering time to iframes, which might be cross-origin
(same-process). This is already observable today, by using
requestAnimationFrame. Underwent internal security review. Note that
everything in this feature is same-process.


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?

N/A


Debuggability



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

https://wpt.fyi/results/long-animation-frame/tentative?label=experimental&label=master&aligned


Flag name on chrome://flagsLongAnimationFrameTiming

Finch feature nameNone

Non-finch justificationNone

Requires code in //chrome?False

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

Launch bughttps://launch.corp.google.com/launch/4244858

Adoption expectationThe origin trial was a big success, and opted into by
both major companies (Wix, Microsoft, Google), smaller companies and
several RUM providers.

Adoption planShipping it in stable (with a minor API change that is
underway) is already on track for wide adoption due to very positive
response to origin trial.

Estimated milestones
Shipping on desktop 123
OriginTrial desktop last 123
OriginTrial desktop first 116
Shipping on Android 123
OriginTrial Android last 123
OriginTrial Android first 116
Shipping on WebView 123
OriginTrial webView last 123
OriginTrial webView first 116
Shipping on WebView 123

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. The issues raised in the TAG reviewed were previously addressed in
the security review of this feature, and need some clarification but not
spec changes.

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

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJn%3DMYbX%3DEOAwkEvDQY9Ja1trSXLFtM1XNsuw1Lr2QR88%2BTnqw%40mail.gmail.com
Intent
to Experiment:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJn%3DMYbdL3atq6FvsfrR%3DVs%2Boexvt04zfjV97BNNPL76iPTGLg%40mail.gmail.com
Intent to Extend Experiment:
https://groups.google.com/a/chromium.org/g/blink-dev/c/MClbXXUhOTs
Intent to Ship:
https://groups.google.com/a/chromium.org/g/blink-dev/c/MClbXXUhOTs


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/CAJn%3DMYZ9AtHwBuXzz%3D7B7wZyrGqbhv5F%2BYVxDm8Lc6TV2LEkDg%40mail.gmail.com.

[blink-dev] RuntimeEnabledFeatures flags that we might be able to remove

2024-01-12 Thread David Baron

Since we've recently been more careful about creating feature flags for
changes that have the possibility of breaking content, we've also been
creating more feature flags than before. This means that we're also
creating a larger number of feature flags that have shipped to stable, been
shown to be safe, and have served their purpose. Many of these flags (and
associated flag-controlled code) can hopefully be removed.

I made a spreadsheet of feature flags that have been shipped in stable

along
with the stable milestone they shipped in. The sheet should be publicly
viewable and editable by any Chromium committer. The sheet itself has
notes about how I made it (briefly: mostly with
third_party/blink/tools/list_stable_features.py).

This sheet is presented as data to help folks remember to remove flags that
they were intending to remove. I'm sure there are a bunch of flags listed
that shouldn't be removed, but also plenty that can be removed (either now
or soon).

Feel free to add notes to the sheet, update owners as needed, and to write
CLs to remove flags that we don't need anymore.

-David

--
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/CAG0MU3ia7vybzAWOADVmqdLhN%2BT7VJsfNcmaLcXAutwZRSpVTQ%40mail.gmail.com.

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

2024-01-12 Thread 'Orr Bernstein' via blink-dev

Thank you, everyone! I really appreciate it.

On Thursday, January 11, 2024 at 5:37:30 PM UTC-5 rby...@chromium.org wrote:

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

Re: [blink-dev] RuntimeEnabledFeatures flags that we might be able to remove

2024-01-12 Thread Xianzhu Wang

It seems that some old public features can also be removed. They have
dedicated --disable-* command line switches or are bound to base features,
but are not much different from the non-public ones which are also
controllable with command line flags
(--disable-features/--disable-blink-features) or through automatically
defined base features. They are public perhaps just because they had
existed before we added new ways to control blink runtime features, such as
WebRuntimeFeatures::EnableFeatureFromString (instead of dedicated
functions) and automatically defined base features.

On Fri, Jan 12, 2024 at 8:39 AM David Baron  wrote:

> Since we've recently been more careful about creating feature flags for
> changes that have the possibility of breaking content, we've also been
> creating more feature flags than before.  This means that we're also
> creating a larger number of feature flags that have shipped to stable, been
> shown to be safe, and have served their purpose.  Many of these flags (and
> associated flag-controlled code) can hopefully be removed.
>
> I made a spreadsheet of feature flags that have been shipped in stable
> 
>  along
> with the stable milestone they shipped in.  The sheet should be publicly
> viewable and editable by any Chromium committer.  The sheet itself has
> notes about how I made it (briefly: mostly with
> third_party/blink/tools/list_stable_features.py).
>
> This sheet is presented as data to help folks remember to remove flags
> that they were intending to remove.  I'm sure there are a bunch of flags
> listed that shouldn't be removed, but also plenty that can be removed
> (either now or soon).
>
> Feel free to add notes to the sheet, update owners as needed, and to write
> CLs to remove flags that we don't need anymore.
>
> -David
>
> --
> 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/CAG0MU3ia7vybzAWOADVmqdLhN%2BT7VJsfNcmaLcXAutwZRSpVTQ%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/CADBxridoK3ZO8AQYDM73M9OAB8aRHx-3Y7bD0DCmsqyavhC9_Q%40mail.gmail.com.

[blink-dev] Intent to Prototype: document.caretPositionFromPoint API

2024-01-12 Thread 'Siye Liu' via blink-dev

Contact emails
si...@microsoft.com, sa...@microsoft.com

Explainer
None

Specification
https://www.w3.org/TR/cssom-view-1/#dom-document-caretpositionfrompoint

Summary

This new API allows users to get current caret position from a given screen 
point. The API returns a CaretPosition object which represents the caret 
position indicating current text insertion point including the containing 
DOM node, caret's character offset, and the client rectangle of caret 
range. 


Blink component
Blink>CSS 


Motivation

document.caretPositionFromPoint API is in CSSOM View and is already 
implemented by Gecko. WebKit/Blink has similar document.caretRangeFromPoint 
API which returns a text range indicating the text insertion point. The 
existing API was in CSSOM View at the time it was implemented: 
https://bugs.webkit.org/show_bug.cgi?id=27046 
http://web.archive.org/web/20090708002518/http://dev.w3.org/csswg/cssom-view/#the-documentview-interface
 
The existing API was replaced by the new API later: 
https://hg.csswg.org/drafts/rev/4c7b6f843171. The switch happened around 
2009 and we don't have the historical context about the decision. Given how 
long it has been since the spec was updated, we believe it's best that 
Blink complies with the spec so that future innovations with the API can be 
spec compliant and have lower interop/compat risk.


Initial public proposal
None

TAG review
None

TAG review status
Not applicable

Risks


Interoperability and Compatibility

Gecko already implemented the API. Webkit/Blink didn't implement it. The 
interop risk is that it's unclear at this moment about Webkit's position on 
this. We won't be able to achieve full interop with this API if Webkit 
isn't willing to support this API. There is a compat risk too if we decided 
to deprecate the old API: https://crbug.com/690599


*Gecko*: Shipped/Shipping

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

*Web developers*: Positive (
https://bugs.chromium.org/p/chromium/issues/detail?id=388976#c34) Web 
developers are asking to have document.caretPositionFromPoint API 
implemented in Blink: 
https://bugs.chromium.org/p/chromium/issues/detail?id=388976#c28 
https://bugs.chromium.org/p/chromium/issues/detail?id=388976#c34

*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


Is this feature fully tested by web-platform-tests 

?
Yes

The API is tested in WPT: 
https://github.com/web-platform-tests/wpt/blob/c18cfd4eb319ca535db8c194941719598b3b6ea8/css/cssom/caretPositionFromPoint.html


Flag name on chrome://flags
None

Finch feature name
None

Non-finch justification
None

Requires code in //chrome?
False

Tracking bug
https://crbug.com/388976

Estimated milestones

No milestones specified


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

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/2618db7c-56d2-4ff2-89c5-df65e1dfe6c7n%40chromium.org.

[blink-dev] Intent to Ship: New ALPS code point

2024-01-12 Thread Victor Tan

Contact emails

victor...@chromium.org, miketa...@chromium.org, david...@chromium.org

Explainer

https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md

Specification

https://tools.ietf.org/html/draft-davidben-http-client-hint-reliability

https://tools.ietf.org/html/draft-vvv-httpbis-alps

https://tools.ietf.org/html/draft-vvv-tls-alps

Summary

Shipping a new code point (17613) for TLS ALPS extension to allow adding
more data in the ACCEPT_CH HTTP/2 and HTTP/3 frame. The ACCEPT_CH HTTP/2
frame with the existing TLS ALPS extension code point (17513) had an
arithmetic overflow bug in the Chrome ALPS
decoder. It limits the capability to add more than 128 bytes data (in
theory, the problem range is 128 bytes to 255 bytes) to the ACCEPT_CH
frame. With the new ALPS code point, we can fully mitigate the issue.

Blink component

Blink>Network>ClientHints

TAG review

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

TAG review status

Closed

Risks
Interoperability and Compatibility

This is switching to a new code point for the TLS ALPS extension. It won’t
change the design of ALPS and ACCEPT_CH mechanism implementation. The main
source of compatibility risk is that it causes conflicts with ALPS
negotiation since some clients could still use the old code point while
others are switching to use the new code point. The ALPS extension could
be ignored if the code point doesn’t match during negotiation, which means
the server's client hints preferences won’t be delivered in the ACCEPT_CH
HTTP/2 and HTTP/3 frame. We mitigate this by enabling servers to support
both code points, monitoring both code points usage and removing the old
ALPS code point support in a future intent once the usage is low enough. We
also split the rollout into two phases: we first start to enable the new
ALPS code point for ACCEPT_CH with HTTP/3 frame in a slow rollout, and
then eventually enable the new code point with HTTP/2 frame.

Edge: No signals

Firefox: Pending https://github.com/mozilla/standards-positions/issues/510
Safari: Pending
https://lists.webkit.org/pipermail/webkit-dev/2021-April/031768.html

Web/Framework developers:
https://twitter.com/Sawtaytoes/status/1369031447940526080
https://twitter.com/_jayphelps/status/1369023028735148032

Activation

The site’s TLS and HTTP serving application would need to be updated to
support this new code point. We aren’t aware of many sites using this
feature yet, however.

Debuggability

No special DevTools support needed. The effects of the code point change of
ACCEPT_CH frame will be visible in the DevTools’ network tab. Also, the
NetLog will record the ACCEPT_CH frame value if TLS ALPS extension is
negotiated successfully.

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

No, this feature is tested with browser-side tests. We can’t test
TLS-adjacent features currently through web-platform-tests. See this issue:
https://github.com/web-platform-tests/wpt/issues/20159

Flag name

UseNewAlpsCodepointHttp2

UseNewAlpsCodepointQUIC

Tracking bug

b/289087287

Launch bug

https://launch.corp.google.com/launch/4299022

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

--
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/2c1aac5d-163f-44e6-b16d-436bb3ea3c3an%40chromium.org.

[blink-dev] Re: Intent to Prototype: document.caretPositionFromPoint API

2024-01-12 Thread Brian Birtles

Hi,

Will this also cover the behavioral differences between 
caretPositionFromPoint as implemented in Gecko and caretRangeFromPoint as 
implemented in Blink such as:

1. caretPositionFromPoint in Gecko digs into shadow DOM elements whereas 
caretRangeFromPoint in Blink does not.
2. When the point is over a text input element, caretPositionFromPoint in 
Gecko returns the text input element and offset into it but 
caretRangeFromPoint in Blink returns the nearest ancestor of the text input 
element. (Note that caretRangeFromPoint in Webkit returns the text input 
element but always returns a zero offset into it.)

Thanks,

Brian

2024年1月13日土曜日 3:35:59 UTC+9 si...@microsoft.com:

> Contact emails
> si...@microsoft.com, sa...@microsoft.com
>
> Explainer
> None
>
> Specification
> https://www.w3.org/TR/cssom-view-1/#dom-document-caretpositionfrompoint
>
> Summary
>
> This new API allows users to get current caret position from a given 
> screen point. The API returns a CaretPosition object which represents the 
> caret position indicating current text insertion point including the 
> containing DOM node, caret's character offset, and the client rectangle of 
> caret range. 
>
>
> Blink component
> Blink>CSS 
> 
>
> Motivation
>
> document.caretPositionFromPoint API is in CSSOM View and is already 
> implemented by Gecko. WebKit/Blink has similar document.caretRangeFromPoint 
> API which returns a text range indicating the text insertion point. The 
> existing API was in CSSOM View at the time it was implemented: 
> https://bugs.webkit.org/show_bug.cgi?id=27046 
> http://web.archive.org/web/20090708002518/http://dev.w3.org/csswg/cssom-view/#the-documentview-interface
>  
> The existing API was replaced by the new API later: 
> https://hg.csswg.org/drafts/rev/4c7b6f843171. The switch happened around 
> 2009 and we don't have the historical context about the decision. Given how 
> long it has been since the spec was updated, we believe it's best that 
> Blink complies with the spec so that future innovations with the API can be 
> spec compliant and have lower interop/compat risk.
>
>
> Initial public proposal
> None
>
> TAG review
> None
>
> TAG review status
> Not applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> Gecko already implemented the API. Webkit/Blink didn't implement it. The 
> interop risk is that it's unclear at this moment about Webkit's position on 
> this. We won't be able to achieve full interop with this API if Webkit 
> isn't willing to support this API. There is a compat risk too if we decided 
> to deprecate the old API: https://crbug.com/690599
>
>
> *Gecko*: Shipped/Shipping
>
> *WebKit*: No signal (
> https://github.com/WebKit/standards-positions/issues/301)
>
> *Web developers*: Positive (
> https://bugs.chromium.org/p/chromium/issues/detail?id=388976#c34) Web 
> developers are asking to have document.caretPositionFromPoint API 
> implemented in Blink: 
> https://bugs.chromium.org/p/chromium/issues/detail?id=388976#c28 
> https://bugs.chromium.org/p/chromium/issues/detail?id=388976#c34
>
> *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
>
>
> Is this feature fully tested by web-platform-tests 
> 
> ?
> Yes
>
> The API is tested in WPT: 
> https://github.com/web-platform-tests/wpt/blob/c18cfd4eb319ca535db8c194941719598b3b6ea8/css/cssom/caretPositionFromPoint.html
>
>
> Flag name on chrome://flags
> None
>
> Finch feature name
> None
>
> Non-finch justification
> None
>
> Requires code in //chrome?
> False
>
> Tracking bug
> https://crbug.com/388976
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5201014343073792
>
> 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/7eeea3be-3d0d-4044-91ab-b951cba3a293n%40chromium.org.

Re: [blink-dev] Intent to Ship: Long Animation Frame Timing

2024-01-12 Thread Yoav Weiss

Thanks for working on this important problem! :)

On Fri, Jan 12, 2024 at 11:31 AM Noam Rosenthal 
wrote:

> Contact emailsnrosent...@chromium.org
>
> Explainer
> https://github.com/w3c/longtasks/blob/loaf-explainer/loaf-explainer.md
>

Can the explainer be updated? e.g. I'm assuming that the "this is a work in
progress... lots of things might change" disclaimer is no longer valid.
Beyond that, the script attribution parts are not really explained outside
of examples. Is there some developer-facing documentation covering that
elsewhere?
For example, it'd be good to cover how code is attributed for async calls,
Promises that got resolved, etc.


>
> Specificationhttps://w3c.github.io/longtasks/
> 
>

The link above is broken. I think you meant
https://w3c.github.io/longtasks/#sec-PerformanceLongTaskTiming

Regarding the spec, I see that it's monkeypatching WebIDL, DOM and HTML.
This feels odd in a WG-adopted spec.
Have you tried to PR these changes upstream?


>
>
> Summary
>
> This is an extension of long tasks. It measures the task together with its
> subsequent rendering update, adding information such as long running
> scripts, rendering time, and time spent in forced layout and style ("layout
> thrashing"). Developers can use this as a diagnostic for "sluggishness",
> which is measured by INP, by finding the causes for main-thread congestion
> which is often the cause for bad INP.
>
>
> Blink componentBlink>PerformanceAPIs
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/911
>

The discussion seems to still be ongoing..


>
>
> TAG review statusIssues addressed
>
> Chromium Trial NameLongAnimationFrameTiming
>
> Link to origin trial feedback summaryhttps://github.com/w3c/longtasks
>
> Origin Trial documentation link
> https://github.com/w3c/longtasks/blob/main/loaf-explainer.md
>
> Risks
>
>
> Interoperability and Compatibility
>
>
>
> *Gecko*: Positive Not yet a formal signal but showed positive interest at
> WG call.
>
> *WebKit*: No signal
>

Can you link to the position requests?


>
> *Web developers*: Positive (
> https://twitter.com/jebbacca/status/1653355406368952321) Wix, Taboola,
> and others have already experimented with this in Canary. Strong excitement
> from several partners at We Love Speed conference.
>
> *Other signals*:
>
> Ergonomics
>
> It should work well with other performance timeline entries, mainly
> event-timing/INP.
>
>
> Security
>
> This feature exposes rendering time to iframes, which might be
> cross-origin (same-process). This is already observable today, by using
> requestAnimationFrame. Underwent internal security review. Note that
> everything in this feature is same-process.
>
>
> 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?
>
> N/A
>
>
> Debuggability
>
>
>
> 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
>
>
> https://wpt.fyi/results/long-animation-frame/tentative?label=experimental&label=master&aligned
>
>
> Flag name on chrome://flagsLongAnimationFrameTiming
>
> Finch feature nameNone
>
> Non-finch justificationNone
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1392685
>
> Launch bughttps://launch.corp.google.com/launch/4244858
>
> Adoption expectationThe origin trial was a big success, and opted into by
> both major companies (Wix, Microsoft, Google), smaller companies and
> several RUM providers.
>
> Adoption planShipping it in stable (with a minor API change that is
> underway) is already on track for wide adoption due to very positive
> response to origin trial.
>
> Estimated milestones
> Shipping on desktop 123
> OriginTrial desktop last 123
> OriginTrial desktop first 116
> Shipping on Android 123
> OriginTrial Android last 123
> OriginTrial Android first 116
> Shipping on WebView 123
> OriginTrial webView last 123
> OriginTrial webView first 116
> Shipping on WebView 123
>
> 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. The issues raised in the TAG reviewed were previously addressed in
> the security review of this feature, and need some clarification but not
> spec changes.
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/featu