Re: [blink-dev] Intent to Ship: NavigationActivation

['Noam Rosenthal' via blink-dev]

On Friday, January 26, 2024 at 5:15:28 PM UTC Vladimir Levin wrote:

On Fri, Jan 26, 2024 at 4:27 AM Noam Rosenthal  
wrote:

Contact emailsjap...@chromium.org, nrose...@chromium.org

Explainer
https://github.com/WICG/view-transitions/blob/main/navigation-activation-explainer.md

Specification
https://html.spec.whatwg.org/multipage/nav-history-apis.html#navigation-activation-interface

Summary

navigation.activation stores state about when the current Document was 
activated (e.g., when it was initialized, or restored from the back/forward 
cache).


Blink componentBlink>History 


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

TAG review statusIssues addressed

Risks


Interoperability and Compatibility

None


*Gecko*: Positive (https://github.com/mozilla/standards-positions/issues/928
)

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

*Web developers*: Positive

*Other signals*:

Security

This is a cross-document (navigation) feature, so designing it we needed to 
take care of cross-origin navigation related risks. Since 
`navigation.activation` is part of the navigation API, it uses the same 
semantics and protections. We only expose things that are otherwise exposed 
by the navigation API or in other means.


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

https://wpt.fyi/results/navigation-api/navigation-activation?label=master=experimental=navigation%20activation


Flag name on chrome://flagsNavigationActivation

Finch feature nameNone

Non-finch justification

It's a web-API, exposing it gradually doesn't make sense.


I'm always unsure about this, but I believe "Finch feature name" is the 
flag you'd put in runtime_enabled_features.json5. It can be used by Finch 
as a kill-switch in case the feature causes some regression in the wild. 
For this feature, the chrome:://flags flag isn't there though (correct me 
if I'm wrong)


According to these guidelines: 
https://chromium.googlesource.com/chromium/src/+/main/third_party/blink/renderer/platform/RuntimeEnabledFeatures.md#guidelines-for-setting-feature-status
Finch + base:: features are used only for things that can cause compat 
issues, not so much for new web APIs.
I was following this guideline, if something else is required here I'd be 
happy to follow up.

-- 
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/8383d18c-5aab-40f9-abad-9118ebe33d61n%40chromium.org.

Re: [blink-dev] Intent to Extend Experiment: WebRTC encoded transform - Modify Metadata functions

[Domenic Denicola]

It's exciting to see the Origin Trial system working as intended, giving us
time to get in-the-field feedback but also stay responsive to ongoing
standards discussions about changing the shape of the API.

Recalling the requirements for extending an origin trial
, we need
to see substantial progress demonstrated in all of the following areas:
draft spec, TAG review, signals requests, outreach for feedback from the
spec community, and WPT tests. I think these have mostly been met, with the
exception of TAG review. Do you think it'd be reasonable to start the TAG
review on the constructor proposal now, or do you think there's still a
significant chance it might change due to WG feedback, such that we're
better of continuing to delay the review?

Also, a question on the explainer below.

On Fri, Jan 26, 2024 at 8:27 PM Guido Urdaneta  wrote:

> Contact emails
>
> gui...@chromium.org, he...@google.com, agpa...@chromium.org
>
>
> Explainer
>
>
> https://github.com/palak8669/webrtc-encoded-transform/blob/create-encoded-explainer/create-encoded-explainer.md
>

Is this explainer up to date with the newest specification proposal? The
specification PR you link below introduces RTCEncodedVideoFrame
and RTCEncodedAudioFrame constructors, but the explainer doesn't seem to
reference either of those. Additionally, the explainer seems to talk about
a clone "operator" (is that a way of saying method?), but I don't see that
in the spec PR.


>
> Specification
>
> https://github.com/w3c/webrtc-encoded-transform/pull/223/files
>
> Original I2E
>
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/yqwA-jXv6VY/m/fCkBkclxAAAJ
>
>
>
> Summary
>
> Add a feature to the WebRTC Encoded Transform API that allows manipulating
> audio and video frame metadata.
>
> Background: A number of use cases have been identified that require the
> manipulation of the metadata of WebRTC encoded frames without decoding them
> first.
>
> These include:
>
> - Receiving data in encoded form and forwarding it.
>
> - Sending data that has been encoded previously
>
> - Sending data that has been received in encoded form
>
> In particular, we want to support the use case of glitch-free forwarding
> of media coming from multiple redundant peer connections that provide the
> same media payloads but with different metadata.
>
> Issue links:  
>
> https://github.com/w3c/webrtc-nv-use-cases/issues/77
>
> https://github.com/w3c/webrtc-nv-use-cases/issues/122
>
> https://github.com/w3c/webrtc-encoded-transform/issues/211
>
>
>
> Blink component
>
> Blink>WebRTC
> 
>
>
> TAG review
>
> The original full spec was reviewed by TAG here:
> https://github.com/w3ctag/design-reviews/issues/531
>
> No TAG review has been requested for this incremental change, since it is
> a small addition and its API surface might change as a result of feedback
> from the origin trial and ongoing discussions in the WebRTC working group.
>
>
> TAG review status
>
> Issues addressed for the original spec. Not yet requested for the
> incremental change.
>
>
> Chromium Trial Name
>
> RTCEncodedFrameSetMetadata
>
>
> WebFeature UseCounter name
>
> V8RTCEncodedVideoFrame_SetMetadata_Method
>
>
> Link to origin trial feedback summary
>
>
> https://docs.google.com/document/d/1oCgXj0bEhJS6WeJ0T-gV5AVhSaEeVixssqm02m4eU9Q/r/0-f4cSv_CIFwIpVPcIKb89TQ/edit?tab=t.0
>
>
>
> Risks
>
>
> Interoperability and Compatibility
>
> Interoperability risk: There is the risk that other browsers will not
> implement this feature. We are mitigating this risk by pursuing consensus
> in the W3C WebRTC Working Group so that it becomes part of the WebRTC
> encoded transform spec supported by all browsers.
>
>
> Compatibility risk: This is a new feature intended to support a new use
> case. It introduces no breaking changes, so we do not expect any
> compatibility issues.
>
>
> Gecko: No signal requested yet. Positive initial feedback during WG
> discussions.
>
>
> WebKit: No signal requested yet. Positive initial feedback during WG
> discussions.
>
>
> Web developers: Positive
>
>
> Other signals:
>
>
> Ergonomics
>
> This feature is an extension to WebRTC Encoded Transform, which itself is
> an extension to WebRTC/RTCPeerConnection.
>
>
> Activation
>
> N/A
>
>
> Security
>
> No new security risks identified.
>
>
> WebView application risks
>
> None
>
>
>
> Reason this experiment is being extended
>
> We have received positive developer feedback and have validated that the
> proposal supports the intended use case, but the API requires some changes
> in order to achieve consensus in the W3C WebRTC Working Group. This is the
> current status:
>
> 1. There is consensus to support the use case, which is already part of
> the official "WebRTC Extended Use Cases" document from the WG. See
> requirement N39 in 

[blink-dev] Blink bug status as of 2024-01-29

[tkent]

Title: Blink bug summary




Blink bug status as of 2024-01-29

Component
Open


Slow Triage
Pri-0/1



⭐
No owner
Oldest


Whole Blink19,267(+33)76,162(+17)1,185(-13)549(+19)147Jan 2015
Uncategorized13(+1)17(+4)1(+1)1(-4)0Jan 2024
Blink>Accessibility597(+2)2,114(+2)57(+3)52(-1)10Feb 2020
Blink>Animation248(-2)9930(-5)00
Blink>AppManifest37(+1)166(+1)2(+1)10Jan 2020
Blink>AudioOutputDevices14(+1)56(+5)000
Blink>BackgroundFetch4480(+1)23103Sep 2018
Blink>BackgroundSync2153863Nov 2020
Blink>BatteryStatus1057722Nov 2016
Blink>Bindings396(+1)1,070530Nov 2023
Blink>Bluetooth119(-3)626(-4)0(-1)21Jan 2020
Blink>CSS546(+12)3,218(+12)0(-1)10(+8)7Nov 2023
Blink>Canvas370(+6)1,515(+15)26(+3)13(-2)1Feb 2022
Blink>CaptureFromElement32131710Jul 2022
Blink>Color19(+1)50(+2)01(+1)0Jan 2024
Blink>Compositing205751(+3)000
Blink>Contacts1330220May 2023
Blink>ContentIndexing422100
Blink>ControlledFrame517210Jul 2023
Blink>DOM227(-1)911(-10)0(-1)15(+7)6Nov 2021
Blink>DataTransfer324(-1)1,620(+1)3(+1)8(+1)0Jun 2021
Blink>DefaultNavigationTransitions30(+1)53(+2)02(+1)0Dec 2023
Blink>DocumentMetadata1023200
Blink>Editing1,0964,295(-22)16(-3)95Jun 2023
Blink>EnumerateDevices30123(+1)110Apr 2022
Blink>FeaturePolicy451641510Oct 2022
Blink>FencedFrames82(-1)216(-1)33(+5)50Jul 2022
Blink>FoldableAPIs658000
Blink>Fonts420(-2)1,883(-20)9(+5)0(-1)0
Blink>Forms5362,373(-19)06(+2)0Nov 2023
Blink>Fullscreen117(+1)380(+5)080Nov 2022
Blink>GamepadAPI121(-1)443(-1)020Feb 2019
Blink>GarbageCollection90(-1)24831(+1)0Jan 2024
Blink>Geolocation51(-1)348(-1)0(-1)70May 2018
Blink>Geometry61(-2)206(-2)01(-1)0Jan 2024
Blink>GetDisplayMedia229(+2)7771122(+3)2Jul 2021
Blink>GetUserMedia136(+1)627(+6)10101Jan 2021
Blink>HID62(+1)222(+2)0(-1)2(+1)0Jan 2021
Blink>HTML612(+1)2,382(-19)012(+5)3Jul 2019
Blink>Handwriting34210Jul 2021
Blink>History46(+1)161(+2)010Dec 2023
Blink>HitTesting48(-1)184(-1)000
Blink>Identity156383(+1)155(-1)0May 2023
Blink>Image105(+2)441(+5)02(+2)0Jan 2024
Blink>ImageCapture24120110Mar 2023
Blink>Infra169(-5)470(-5)7(-1)3(-2)1Dec 2023
Blink>Input845(-1)3,079(-2)14(-6)4(-2)0Apr 2023
Blink>InterestCohort37300
Blink>InterestGroups100(+1)328(+3)59(+5)5(+1)3Jul 2022
Blink>Internals167(+3)574(+4)651712Aug 2021
Blink>_javascript_1,585(+31)4,226(+23)118(+10)37(+4)18Aug 2023
Blink>Layout1,021(-13)3,956(-41)10(-2)37(-10)18Sep 2023
Blink>LazyLoad4620
Blink>Loader532(-4)2,5059(-4)8(-2)0May 2023
Blink>Managed24100
Blink>MathML30(-1)111(-16)400
Blink>Media883(+2)3,035(-7)13(+3)18(+1)2Jun 2021
Blink>MediaRecording74(+2)285310Nov 2023
Blink>MediaStream111(+1)4751151Nov 2021
Blink>MemoryAllocator218(-7)602(-9)9(-4)8(-2)1Jun 2022
Blink>Messaging3815320(+1)00
Blink>NFC7410(-1)00
Blink>Network460(-1)2,271(-3)17(+2)10(+1)0Aug 2015
Blink>PageCollections0
Blink>PageLifecycle50201000
Blink>Paint613(-5)2,301(-4)2(-1)3(-1)1Nov 2023
Blink>Payments155(-1)418(-5)0(-2)7(+1)1Dec 2022
Blink>PerformanceAPIs248(-2)959(-10)2(-9)60Mar 2023
Blink>PermissionsAPI37(-1)167(-3)1200
Blink>PermissionsPolicy613210Sep 2023
Blink>Portals98(-1)305(-1)2(+1)00
Blink>PresentationAPI39138000
Blink>Previews33100
Blink>PrivateAggregation1966(-1)000
Blink>PushAPI391711320Aug 2022
Blink>ReportingObserver1022000
Blink>SVG3141,805(+22)030Mar 2023
Blink>SavePage1156738963Jan 2015
Blink>Scheduling196(-2)1,768(-8)49(-1)30May 2020
Blink>Screen743621(+1)40Oct 2021
Blink>ScreenOrientation28691911Mar 2021
Blink>Scroll804(-8)3,094(+2)13(-8)0(-1)0
Blink>SecurityFeature599(-1)2,535(-9)0(-2)10(+1)2Jan 2020
Blink>Sensor31(+1)158(+1)000
Blink>Serial42173(+1)1(-1)11Nov 2023
Blink>ServiceWorker356(+6)1,601(+23)1(-2)10(+4)5Dec 2022
Blink>ShapeDetection2310
Blink>SmartCard4(-2)15(-1)10(-1)0
Blink>Speech15368012084Sep 2019
Blink>Storage669(-1)3,80310(-1)25(-1)2Aug 2021
Blink>StorageAccessAPI1779(+1)1010Dec 2023
Blink>TextAutosize32(+1)274(+1)1(+1)00
Blink>TextEncoding27(-1)96(-1)000
Blink>TopicsAPI1539910Feb 2022
Blink>URLPattern513300
Blink>USB54(-1)288(-2)1(+1)20Jan 2021
Blink>Vibration1022900
Blink>ViewSource2292000
Blink>ViewTransitions45(-1)109(-2)000
Blink>WakeLock1059(+1)100
Blink>WebAudio175(+3)864(+1)110(-1)3May 2022
Blink>WebAuthentication171(+6)501(+15)5315(+4)13Apr 2023
Blink>WebCrypto30912300
Blink>WebFonts28131200
Blink>WebGL612(+7)2,211(+18)4(-1)20(+2)2Sep 2021
Blink>WebGPU196(+1)639(+3)36(+2)63May 2023
Blink>WebHD12000
Blink>WebMIDI32157010Sep 2021
Blink>WebML49(+5)100(+5)27(+1)3(-1)2Aug 2023
Blink>WebOTP301151300
Blink>WebRTC560(+6)2,552(-5)39(+2)48(+4)5Feb 2018
Blink>WebShare55304(+1)131Oct 2022
Blink>WebXR100423000
Blink>WindowDialog71(-1)640(-9)010Oct 2023
Blink>Workers178(-4)969(-4)3(-2)40May 2023
Blink>XML34(-1)167(-1)000



A value is the number of bugs in a component and its sub-components.
e.g. The 'Blink>Layout' row contains all of bugs in sub-components of
Blink>Layout in addition to Blink>Layout bugs.
The data was fetched with a permission of a general @google.com account.
It takes account of non-public bugs, but doesn't have the owner field and
the open date field 

Re: [blink-dev] PSA: Protected Audience k-Anonymity Enforcement

[Mike Taylor]

Thanks - it looks like there are no real compatibility concerns from 
perspective of sites _breaking_ for users. Given that, a PSA for this 
change sounds fine to me.


later,
Mike

On 1/26/24 10:38 AM, Russ Hamilton wrote:
Most users should not notice a difference. The main difference is 
going to be which ads are allowed to win Protected Audience auctions. 
Some non-k-anonymous ads that would have previously won the Protected 
Audience auction will not win and the auction will return a different, 
k-anonymous ad as the winner. In the case where there are no 
k-anonymous bids in an auction then that auction will return without a 
winner. Protected Audience auctions already return with no winner in 
some cases, such as when there are no bids, so this does not introduce 
a new behavior.


On Fri, Jan 26, 2024 at 4:24 AM Mike Taylor  
wrote:


Hi Russ,

Can you say more about the compatibility implications for such a
change? AFAIU, things shouldn't "break" for users or throw errors
behind the scenes, correct?

thanks,
Mike

On 1/26/24 12:59 AM, 'Russ Hamilton' via blink-dev wrote:

We plan to start enabling the k-anonymity

enforcement
feature for the Protected Audience API
(Intent
to Ship

).
K-anonymity enforcement has long been a part of the Protected
Audience API’s plan for improving user privacy by limiting ads
that can win Protected Audience auctions to those ads that are
k-anonymous. The k-anonymity enforcement feature limits the
ability of advertisers to target specific users by requiring each
ad be shown to a minimum number of users. This enforcement will
initially apply to up to 20% of unlabeled traffic only, meaning
the groups that are part of Chrome-facilitated testing

for
third-party cookie deprecation will not be enforced for
k-anonymity during the testing period. After the testing period,
enforcement will apply to all traffic (see timeline details at

https://developers.google.com/privacy-sandbox/relevance/protected-audience-api/k-anonymity

).
-- 
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/CAAG-DU2%3DfH8Q5gDDVms%2BajMA4WzS%3DvQBRPQj8jaiVzJkCdCz7g%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/0a547272-52c9-47a0-b12d-d6125edf0968%40chromium.org.

Re: [blink-dev] Intent to deprecate and remove import assertion 'assert' syntax

[Anton Bershanskyi]

For the record, relevant V8 commit landed with removal planned for V8 
12.6.[1]

[1] 
https://chromium.googlesource.com/v8/v8/+/ae5a4db8ad86c817f80856901ea121829f8b5184%5E%21/

On Wednesday, December 20, 2023 at 6:42:53 PM UTC+2 Daniel Bratell wrote:

> LGTM3 for the plan as outlined by Mike and Philip.
>
> /Daniel
> On 2023-12-14 10:18, Philip Jägenstedt wrote:
>
> On Wed, Dec 13, 2023 at 6:10 PM Shu-yu Guo  wrote:
>
>> On Wed, Dec 13, 2023 at 9:03 AM Philip Jägenstedt  
>> wrote:
>>
>>> LGTM2 for Mike's plan of deprecating for 3 milestones, doing outreach, 
>>> and then revisiting this thread. 
>>>
>>> If we still know of serious breakage after this, is it an option to 
>>> simply support both keywords indefinitely, but treat `assert` as legacy? 
>>> Documentation, linters and autoformatters could all direct developers to 
>>> `with`, without breaking any existing sites.
>>>
>>
>> Yes, it is an option to support both keywords indefinitely and treat 
>> `assert` as legacy. TC39 consensus includes `assert` legacy support, on 
>> account of Chrome having shipped in good faith. We're trying to remove it 
>> for maximal interop since no other browsers shipped `assert`, but if it's 
>> not feasible it will not be a willful violation of spec to continue 
>> shipping it.
>>
>
> I see, thank you for clarifying. Looking forward to seeing what the 
> deprecation and outreach result in.
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to blink-dev+...@chromium.org.
>
> To view this discussion on the web visit 
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYetzaKxSi_yWTCHd4xJrLh1OAY4YQBdwEN1cHd22kUnoA%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/3b465b02-266e-4c00-bf8a-9b1b4f77e879n%40chromium.org.