[blink-dev] MakeFromStream is not available in Canvaskit

[Steven Whelan]

Hi,
In C++,I am trying to read a .skp file as SKPicture as below

const char* skpFilePath = "layer_0.skp";
SkFILEStream stream(skpFilePath);
sk_sp skPicture =SkPicture::MakeFromStream();
canvas->drawPicture(skPicture.get());

This C++ code works fine. I want to do this in browser. I believe skia
cannot run in browser without CanvasKit js binding.

But I cannot find any of these methods in Canvaskit.
I don't think there is any way to run a native C++ command in browser other
than using JS bindings.

-- 
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/CAO%2BCLgBrr%3Dx2Jot60NipZNLu-aVY5zmroXx%2Bs%3DaY%3D8W5bRiuew%40mail.gmail.com.

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

['Sahir Vellani' via blink-dev]

I've published the spec PR. Since I can't update the links in the original 
comment of this thread, I'd like to link the updated explainer here for 
visibility.  pointer-event-extensions/pointer-event-device-id-explainer.md 
at main · WICG/pointer-event-extensions (github.com) 

I have added comments to both request-for-positions informing of the 
changes to the API. 
Thanks for your comments Dan!

On Wednesday, May 8, 2024 at 6:10:48 PM UTC-7 dan...@microsoft.com wrote:

> A non-blocking comment: now that the syntax has been changed I think it 
> would be great if you could update the Explainer and the Mozilla and WebKit 
> requests-for-position to reduce potential for confusion.
>
> Also, is there a reason the spec PR is still in Draft status? Could it be 
> published so that there's no ambiguity for reviewers that this is 
> (hopefully) moving forward imminently?
>
> -- Dan
>
> On Wednesday, May 8, 2024 at 2:00:38 PM UTC-7 sahir.vellani via 
> Chromestatus wrote:
>
>> This is ready for another review :)
>>
>

-- 
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/52090dcd-f068-456d-be41-bfadbb9055d1n%40chromium.org.

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

['Dan Clark' via blink-dev]

A non-blocking comment: now that the syntax has been changed I think it 
would be great if you could update the Explainer and the Mozilla and WebKit 
requests-for-position to reduce potential for confusion.

Also, is there a reason the spec PR is still in Draft status? Could it be 
published so that there's no ambiguity for reviewers that this is 
(hopefully) moving forward imminently?

-- Dan

On Wednesday, May 8, 2024 at 2:00:38 PM UTC-7 sahir.vellani via 
Chromestatus wrote:

> This is ready for another review :)
>

-- 
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/561999ca-3d52-4513-b9bf-161d01881a7bn%40chromium.org.

Re: [blink-dev] Intent to Ship: Tabbed web apps

[Daniel Murphy]

We don't have an objection to this feature existing - it's actually
currently in our backlog. But it is very low in our priority list. While we
can review patches, we will not be able to dedicate resources for
consultation or maintenance.

On Wed, May 8, 2024 at 9:19 AM Brett Wilson  wrote:

> On Wed, May 8, 2024 at 8:39 AM Alex Russell 
> wrote:
>
>> I'm happy for this to be CrOS first, but would like to unpack Brett's
>> statement above a bit. If we (MSFT) were to polish this up for Windows,
>> would patches for that be accepted?
>>
>
> I can't speak for the browser team. But my current understanding is that
> the browser team likes this in principle but doesn't prioritize it high
> enough to work on it right now (this is a correction from my previous
> assertion). So I'm pretty sure patches enabling this for other platforms
> would be accepted.
>
> Brett
>
> --
> 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/CABiGVV-Zeyv3Rez%2BPQ%2B%2BfW4ihpRCwnnGN2HNxOyXTA7_uWehzw%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/CA%2B4qT32O-zoM4tarHQvoHkmYt%2B%3Dc5iOiPdkueMk%2BhUe7mkYU%2BA%40mail.gmail.com.

Re: [blink-dev] Running WebGPU on Amazon EC2 Windows instance

[Ken Russell]

Hi Wenhan,

Would you join https://groups.google.com/a/chromium.org/g/graphics-dev and
post your question there? Several Microsoft colleagues are on that list and
may be able to confirm support.

-Ken



On Wed, May 8, 2024 at 11:46 AM wenhan chong  wrote:

> Thanks François,
> I am not able to follow the steps completely because they are using Linux
> instances while I am trying to run WebGPU on Windows Server 2022.
> Nevertheless, I installed nvidia drivers and vulkan runtime for Windows
> but Chrome is still unable to detect the GPU.
> Does Chrome on Windows Server support WebGPU out of the box?
>
> On Monday 6 May 2024 at 22:24:21 UTC+8 François Beaufort wrote:
>
>> https://developer.chrome.com/blog/supercharge-web-ai-testing is the
>> first part.
>>
>>
>> On Mon, May 6, 2024 at 4:23 PM François Beaufort 
>> wrote:
>>
>>> Hello Wen Han,
>>> May I recommend
>>> https://developer.chrome.com/docs/web-platform/webgpu/colab-headless if
>>> you haven't read it yet?
>>>
>>> On Mon, May 6, 2024 at 4:20 PM wenhan chong  wrote:
>>>
 Hi All,

 I am trying to run WebGPU on an Amazon EC2 Windows instance but I am
 unable to get the browser to detect WebGPU. I have nvidia drivers and
 chrome v124 installed on the instance but requestAdapter still fails for
 WebGPU. I can render WebGL2 just fine. Are there any additional flags or
 libraries I need to install to be able to use WebGPU on EC2?

 Regards,
 Wen Han

 --
 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/6084010a-6302-4c1d-937d-d2c65ad45663n%40chromium.org
 
 .

>>> --
> 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/3dc4204e-b9cc-4461-ac41-58d06b4c9d1en%40chromium.org
> 
> .
>

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

[blink-dev] Intent to Ship: Automatic Fullscreen Content Setting

[Mike Wasserman]

Contact emails

m...@chromium.org, fugu-...@chromium.org

Explainer

https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture

Specification

https://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen

Design docs

https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture

Summary

A new "Automatic Fullscreen" content setting permits
Element.requestFullscreen() without a user gesture, and permits browser
dialogs to appear without exiting fullscreen.

The setting is blocked by default and sites cannot prompt for permission.
New UI controls are limited to Chrome's settings pages [1] and the site
info bubble. Users can allow Isolated Web Apps [2], and enterprise admins
can allow additional origins with the AutomaticFullscreenAllowedForUrls
policy.

Combined with Window Management permission [3] and unblocked popups [4],
this unlocks valuable fullscreen capabilities:

- Open a fullscreen popup on another display, from one gesture

- Show fullscreen content on multiple displays from one gesture

- Show fullscreen content on a new display, when it's connected

- Swap fullscreen windows between displays with one gesture

- Show fullscreen content after user gesture expiry or consumption

[1] chrome://settings/content/automaticFullScreen and site details pages

[2] User control is initially scoped to security-sensitive apps; see
https://chromestatus.com/feature/5146307550248960

[3] For multi-screen window placement features; see
https://chromestatus.com/feature/5252960583942144

[4] To similarly permit window.open() without a user gesture; see
chrome://settings/content/popups

Blink component

Blink>Fullscreen


Search tags

Fullscreen ,
requestFullscreen ,
transient activation
, user
gesture , content
setting 

TAG review

N/A. This is not proposing a new or changed web API, but a browser-specific
permission configuration.

RisksInteroperability and Compatibility

Element.requestFullscreen() may now succeed instead of rejecting without
transient activation. The design doc considers some nuanced windowing
corner cases. This feature is initially only available to
security-sensitive apps and enterprise allow-listed origins.

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

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

Web developers: Positive. Requested by 1st and 3rd party partners,
particularly around VDI: https://github.com/w3c/window-management/issues/7
https://github.com/w3c/window-management/issues/98
https://github.com/w3c/window-management/issues/92
https://crbug.com/315859364

Ergonomics

The explainer discusses prospective feature detection support.

Activation

Users or admins must grant the new Automatic Fullscreen content setting,
plus the Popups & Redirects content setting and the Window Management
permission, and to take full advantage of fullscreen windowing features.

Security

This capability exacerbates preexisting fullscreen usable security
concerns, so sites cannot show a permission prompt, and user controls are
initially scoped to IWA contexts.

WebView application risks

None; this feature is not supported on WebView for now

Debuggability

Sites can debug via Element.requestFullscreen()'s promise, which may reject
with a TypeError containing a message, the document `fullscreenElement`
property, document `fullscreenchange` + `fullscreenerror` events, and
devtools console messages. Transient activation state is exposed via
navigator.userActivation.isActive. Script can check the
window.location.href's scheme for `isolated-app:` to assess initial
availability of user control for the current context.

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

No; Initial support targets desktop platforms.

Is this feature fully tested by web-platform-tests

?

No; WPT coverage is not yet available, and necessitates test driver
controls for this new content setting.

DevTrial instructions

https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture/blob/main/HOWTO.md

Flag name on chrome://flags

chrome://flags/#automatic-fullscreen-content-setting

Finch feature name

AutomaticFullscreenContentSetting

Requires code in //chrome?

True (Chrome settings pages, page info bubble, enterprise policy
integration)

Tracking bug

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

Launch bug

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

Measurement

[blink-dev] Intent to Ship: Stop modifying author-defined selection colors

[Stephen Chenney]

Contact emailsschen...@chromium.org

ExplainerNone

Specificationhttps://www.w3.org/TR/css-pseudo-4/#highlight-selectors

SummaryChromium currently checks all selection highlight colors against the
text color and inverts the highlight color if it matches the text. Hence,
author-defined ::selection CSS properties may be modified by the browser
despite explicit author intent. For example, a CSS rule "::selection {
color: cyan; background: cyan; }" the background is inverted and red color
is used. In https://github.com/w3c/csswg-drafts/issues/6150 the CSS Working
Group resolved to disallow the chromium behavior. We propose to implement
this spec change and bring chromium into compatibility with other browsers.

Blink componentBlink>CSS


TAG reviewNone

TAG review statusNot applicable

Risks


Interoperability and Compatibility

Low risk. Gecko and WebKit both respect author colors from
::selection already. The change makes chromium compatible. It is highly
unlikely that authors are depending on chromium behavior given it is hard
to predict and the number of people who have looked at the workarounds.
Note the workarounds (adding some transparency) will not be broken by the
change.


*Gecko*: Shipped

*WebKit*: Shipped

*Web developers*:
https://stackoverflow.com/questions/14970891/css-selection-color-behaving-strangely-on-chrome

*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

Improved because the rendered result now matches the colors specified by
authors and reported in DevTools.


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

Flag name on chrome://flagsNone

Finch feature nameSelectionRespectsColors

Non-finch justification

The change has been behind Experimental Web Platform Features for 4 months,
with no issues reported.


Requires code in //chrome?False

Tracking bughttps://issues.chromium.org/issues/40771258

Estimated milestones
Shipping on desktop 127
Shipping on Android 127

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/5657973985640448?gate=6583848377253888

-- 
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/CAGsbWzRMGvrzVNmHyJzbgw-fjwBi%2BJm8O0UCt-ZPRF%2BdBN_ddQ%40mail.gmail.com.

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

[sahir.vellani via Chromestatus]

This is ready for another review :)

-- 
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/8828310617f797fe%40google.com.

[blink-dev] Re: Intent to Prototype: Link rel=payment to support push payments

['Junhui He' via blink-dev]

WICG proposal was sent out at https://github.com/WICG/proposals/issues/150

On Wed, May 8, 2024 at 11:03 AM Junhui He  wrote:

> Contact emailsaneesh...@google.com, junhu...@google.com
>
> Explainer
> https://github.com/aneeshali/paymentlink/blob/main/docs/explainer.md
>
> Summary
>
> Adds support for  as a hint that the
> browser should notify registered payment clients about a pending push
> payment. When Blink encounters this HTML element, then it will send a
> message to the browser to display the user's interface to ask the user if
> they would like to invoke Google Pay to assist payments on this page.
>
> Blink componentBlink>Payments
> 
>
> Motivation
>
> This feature lets the browser assist users in push-based payment flows by
> facilitating the transfer of payment information between the payment
> provider (on the payee side) and the payment client (on the payer side).
> The feature lays the foundation for payment integrators in streamlining
> push-based payment flows, towards a consistent and low-friction user
> experience.
>
> Risks
> Interoperability and Compatibility
>
> We're not aware that anybody else uses payment link .
>
> *Gecko*: No signal
>
> *WebKit*: No signal
>
> *Web developers*: No 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
>
> Flag name on chrome://flags#enable-payment-link-detection
>
> Finch feature name"EnablePaymentLinkDetection"
>
> Requires code in //chrome?True - Detection of the payment link does not
> need coding //chrome, but code in //chrome will eventually be required to
> invoke Google Pay APIs.
>
> Tracking bughttps://crbug.com/1477049
>
> Estimated milestones
>
> M132
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5198846820352000?gate=5076188191522816
>
>

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

Re: [blink-dev] Re: Intent to Experiment: Captured Surface Control

['Elad Alon' via blink-dev]

Thank you!

On Wed, May 8, 2024 at 10:20 PM Chris Harrelson 
wrote:

> Sounds fine to me - consider it renumbered from 124.
>
> On Wed, May 8, 2024 at 1:13 PM 'Elad Alon' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Hello Blink owners,
>>
>> We are asking that the OT period on this experiment be shifted, and
>> instead of the originally requested period of m122-m127 (inclusive), we
>> consider it retroactively as m124-m129 (inclusive).
>>
>> As of the time of writing, there has only ever been one active OT
>> participant (Meet), and they only started widespread use of the feature in
>> m124. Further, the feature was not fully implemented until m124. (The
>> initial target of m122 was set based on timelines that did not materialize,
>> both in terms of the feature’s implementation and of participants’
>> implementation.)
>>
>> With respect to standardization:
>>
>> When this API was first presented to Web developers in the Screen Capture
>> CG, we heard a lot of support for it. Since then, we prioritized
>> implementation and validation of the API with partners. Now that we have
>> the thumbs-up on implementation from partners, we are prioritizing
>> standardization. An initial outreach to Mozilla and Apple during the WebRTC
>> WG editors meeting started out positively, and I am looking forward to
>> presenting this to a wider audience during the May interim meeting of the
>> WebRTC WG. The prospects on achieving consensus before m129 runs its course
>> appear good.
>>
>> Thanks,
>>
>> Elad
>>
>>
>> On Thursday, January 18, 2024 at 2:33:24 AM UTC+1 mike...@chromium.org
>> wrote:
>>
>>> Oops, missed Chris' email on this. But you're double approved now. :)
>>> On 1/17/24 8:32 PM, Mike Taylor wrote:
>>>
>>> LGTM to experiment from M122 to M127 inclusive.
>>> On 1/17/24 9:09 AM, 'Elad Alon' via blink-dev wrote:
>>>
>>> A quick clarification, btw, that we have a partner in mind that's eager
>>> to start origin trial as soon as m122.
>>> We also heard interest from other parties during Screen Capture CG
>>> meetings.
>>>
>>> On Wednesday, January 17, 2024 at 2:47:43 PM UTC+1 Elad Alon wrote:
>>>
 Contact emails elad...@chromium.org

 Explainer
 https://github.com/screen-share/captured-surface-control/blob/main/README.md

 Specification TBD, but will be hosted on
 https://screen-share.github.io/captured-surface-control once produced.
 For the time being, please refer to the explainer
 ,
 which has a detailed description of the API as well as sample use of it.
 A demo  is also
 available. (Some of the functionality is still being landed in Chromium
 atm.)

 Design docs
 https://docs.google.com/document/d/10UojDvTJ6ojBEOP7cgBIIaE7WZEfes_Qv1eN3A2A0nM/edit?usp=sharing

 Summary

 Web API that allows Web applications to: 1. Produce wheel events in a
 captured tab or window. 2. Read/write the zoom level of a captured tab.


 Blink component Blink>GetDisplayMedia
 

 TAG review Not started.

 TAG review status Pending. We expect that developer feedback during
 the origin trial might lead to non-trivial changes to the API shape, and
 would therefore like to hold off on TAG review until after those changes.

 Risks


 Interoperability and Compatibility

 *Gecko*: No signal

 *WebKit*: No signal

 *Web developers*: No signals

 *Other signals*:

 Security


 https://github.com/screen-share/captured-surface-control?tab=readme-ov-file#security-and-privacy-concerns


 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?


 Goals for experimentation Validate the API shape with Web developers
 and gather feedback on such topics as:

- Usefulness of the API as currently implemented.
- Usefulness of allowing the API to be invoked while the capturing
page is not focused (currently, the capturing page must be focused).
- Possible pain points with scrolling as currently specified and
implemented. (Is more fine-grained control necessary? Is scrolling too
janky as currently specified and implemented?)


 Ongoing technical constraints None

 Debuggability N/A

 Will this feature be supported on all six Blink platforms (Windows,
 Mac, Linux, ChromeOS, Android, and Android WebView)? No (Supported on
 all desktop platforms. Screen-sharing is not currently supported on mobile
 platforms.)

 Is this feature fully tested by web-platform-tests
 

Re: [blink-dev] Re: Intent to Experiment: Captured Surface Control

[Chris Harrelson]

Sounds fine to me - consider it renumbered from 124.

On Wed, May 8, 2024 at 1:13 PM 'Elad Alon' via blink-dev <
blink-dev@chromium.org> wrote:

> Hello Blink owners,
>
> We are asking that the OT period on this experiment be shifted, and
> instead of the originally requested period of m122-m127 (inclusive), we
> consider it retroactively as m124-m129 (inclusive).
>
> As of the time of writing, there has only ever been one active OT
> participant (Meet), and they only started widespread use of the feature in
> m124. Further, the feature was not fully implemented until m124. (The
> initial target of m122 was set based on timelines that did not materialize,
> both in terms of the feature’s implementation and of participants’
> implementation.)
>
> With respect to standardization:
>
> When this API was first presented to Web developers in the Screen Capture
> CG, we heard a lot of support for it. Since then, we prioritized
> implementation and validation of the API with partners. Now that we have
> the thumbs-up on implementation from partners, we are prioritizing
> standardization. An initial outreach to Mozilla and Apple during the WebRTC
> WG editors meeting started out positively, and I am looking forward to
> presenting this to a wider audience during the May interim meeting of the
> WebRTC WG. The prospects on achieving consensus before m129 runs its course
> appear good.
>
> Thanks,
>
> Elad
>
>
> On Thursday, January 18, 2024 at 2:33:24 AM UTC+1 mike...@chromium.org
> wrote:
>
>> Oops, missed Chris' email on this. But you're double approved now. :)
>> On 1/17/24 8:32 PM, Mike Taylor wrote:
>>
>> LGTM to experiment from M122 to M127 inclusive.
>> On 1/17/24 9:09 AM, 'Elad Alon' via blink-dev wrote:
>>
>> A quick clarification, btw, that we have a partner in mind that's eager
>> to start origin trial as soon as m122.
>> We also heard interest from other parties during Screen Capture CG
>> meetings.
>>
>> On Wednesday, January 17, 2024 at 2:47:43 PM UTC+1 Elad Alon wrote:
>>
>>> Contact emails elad...@chromium.org
>>>
>>> Explainer
>>> https://github.com/screen-share/captured-surface-control/blob/main/README.md
>>>
>>> Specification TBD, but will be hosted on
>>> https://screen-share.github.io/captured-surface-control once produced.
>>> For the time being, please refer to the explainer
>>> ,
>>> which has a detailed description of the API as well as sample use of it.
>>> A demo  is also available.
>>> (Some of the functionality is still being landed in Chromium atm.)
>>>
>>> Design docs
>>> https://docs.google.com/document/d/10UojDvTJ6ojBEOP7cgBIIaE7WZEfes_Qv1eN3A2A0nM/edit?usp=sharing
>>>
>>> Summary
>>>
>>> Web API that allows Web applications to: 1. Produce wheel events in a
>>> captured tab or window. 2. Read/write the zoom level of a captured tab.
>>>
>>>
>>> Blink component Blink>GetDisplayMedia
>>> 
>>>
>>> TAG review Not started.
>>>
>>> TAG review status Pending. We expect that developer feedback during the
>>> origin trial might lead to non-trivial changes to the API shape, and would
>>> therefore like to hold off on TAG review until after those changes.
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> *Gecko*: No signal
>>>
>>> *WebKit*: No signal
>>>
>>> *Web developers*: No signals
>>>
>>> *Other signals*:
>>>
>>> Security
>>>
>>>
>>> https://github.com/screen-share/captured-surface-control?tab=readme-ov-file#security-and-privacy-concerns
>>>
>>>
>>> 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?
>>>
>>>
>>> Goals for experimentation Validate the API shape with Web developers
>>> and gather feedback on such topics as:
>>>
>>>- Usefulness of the API as currently implemented.
>>>- Usefulness of allowing the API to be invoked while the capturing
>>>page is not focused (currently, the capturing page must be focused).
>>>- Possible pain points with scrolling as currently specified and
>>>implemented. (Is more fine-grained control necessary? Is scrolling too
>>>janky as currently specified and implemented?)
>>>
>>>
>>> Ongoing technical constraints None
>>>
>>> Debuggability N/A
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, ChromeOS, Android, and Android WebView)? No (Supported on all
>>> desktop platforms. Screen-sharing is not currently supported on mobile
>>> platforms.)
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ? No (but we're working on it)
>>>
>>> Flag name on chrome://flags captured-surface-control
>>>
>>> Finch feature name CapturedDisplaySurface
>>>

Re: [blink-dev] Re: Intent to Experiment: Captured Surface Control

['Elad Alon' via blink-dev]

Hello Blink owners,

We are asking that the OT period on this experiment be shifted, and instead 
of the originally requested period of m122-m127 (inclusive), we consider it 
retroactively as m124-m129 (inclusive).

As of the time of writing, there has only ever been one active OT 
participant (Meet), and they only started widespread use of the feature in 
m124. Further, the feature was not fully implemented until m124. (The 
initial target of m122 was set based on timelines that did not materialize, 
both in terms of the feature’s implementation and of participants’ 
implementation.)

With respect to standardization:

When this API was first presented to Web developers in the Screen Capture 
CG, we heard a lot of support for it. Since then, we prioritized 
implementation and validation of the API with partners. Now that we have 
the thumbs-up on implementation from partners, we are prioritizing 
standardization. An initial outreach to Mozilla and Apple during the WebRTC 
WG editors meeting started out positively, and I am looking forward to 
presenting this to a wider audience during the May interim meeting of the 
WebRTC WG. The prospects on achieving consensus before m129 runs its course 
appear good.

Thanks,

Elad


On Thursday, January 18, 2024 at 2:33:24 AM UTC+1 mike...@chromium.org 
wrote:

> Oops, missed Chris' email on this. But you're double approved now. :)
> On 1/17/24 8:32 PM, Mike Taylor wrote:
>
> LGTM to experiment from M122 to M127 inclusive.
> On 1/17/24 9:09 AM, 'Elad Alon' via blink-dev wrote:
>
> A quick clarification, btw, that we have a partner in mind that's eager to 
> start origin trial as soon as m122. 
> We also heard interest from other parties during Screen Capture CG 
> meetings.
>
> On Wednesday, January 17, 2024 at 2:47:43 PM UTC+1 Elad Alon wrote:
>
>> Contact emails elad...@chromium.org
>>
>> Explainer 
>> https://github.com/screen-share/captured-surface-control/blob/main/README.md
>>
>> Specification TBD, but will be hosted on 
>> https://screen-share.github.io/captured-surface-control once produced. 
>> For the time being, please refer to the explainer 
>> ,
>>  
>> which has a detailed description of the API as well as sample use of it.
>> A demo  is also available. 
>> (Some of the functionality is still being landed in Chromium atm.)
>>
>> Design docs 
>> https://docs.google.com/document/d/10UojDvTJ6ojBEOP7cgBIIaE7WZEfes_Qv1eN3A2A0nM/edit?usp=sharing
>>
>> Summary 
>>
>> Web API that allows Web applications to: 1. Produce wheel events in a 
>> captured tab or window. 2. Read/write the zoom level of a captured tab.
>>
>>
>> Blink component Blink>GetDisplayMedia 
>> 
>>
>> TAG review Not started.
>>
>> TAG review status Pending. We expect that developer feedback during the 
>> origin trial might lead to non-trivial changes to the API shape, and would 
>> therefore like to hold off on TAG review until after those changes.
>>
>> Risks 
>>
>>
>> Interoperability and Compatibility 
>>
>> *Gecko*: No signal
>>
>> *WebKit*: No signal
>>
>> *Web developers*: No signals
>>
>> *Other signals*:
>>
>> Security 
>>
>>
>> https://github.com/screen-share/captured-surface-control?tab=readme-ov-file#security-and-privacy-concerns
>>
>>
>> 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?
>>
>>
>> Goals for experimentation Validate the API shape with Web developers and 
>> gather feedback on such topics as:
>>
>>- Usefulness of the API as currently implemented. 
>>- Usefulness of allowing the API to be invoked while the capturing 
>>page is not focused (currently, the capturing page must be focused). 
>>- Possible pain points with scrolling as currently specified and 
>>implemented. (Is more fine-grained control necessary? Is scrolling too 
>>janky as currently specified and implemented?) 
>>
>>
>> Ongoing technical constraints None
>>
>> Debuggability N/A
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac, 
>> Linux, ChromeOS, Android, and Android WebView)? No (Supported on all 
>> desktop platforms. Screen-sharing is not currently supported on mobile 
>> platforms.)
>>
>> Is this feature fully tested by web-platform-tests 
>> 
>> ? No (but we're working on it)
>>
>> Flag name on chrome://flags captured-surface-control
>>
>> Finch feature name CapturedDisplaySurface
>>
>> Requires code in //chrome? False
>>
>> Tracking bug 
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1466247
>>
>> Launch bug https://launch.corp.google.com/launch/4268170
>>
>> Estimated milestones 
>> OriginTrial desktop last 127 

Re: [blink-dev] Intent to Implement and Ship: Conversion to RGB in VideoFrame.copyTo()

['Eugene Zemtsov' via blink-dev]

This feature has Privacy, Security, Enterprise, and Debuggability
approvals. Webkit gave a positive signal.

Any objections or questions from the API owners?



On Wed, May 1, 2024 at 4:26 PM Eugene Zemtsov  wrote:

> I've filed issues for TAG review and firefox and webkit positions.
>
> >  Have you looked into other platform APIs that could benefit from being
> able to explicitly specify intermediate format hinting and/or
> transformation?
> I don't think this kind of review can be done for all web APIs by one
> person. It's up to spec editors in each area to identify these small
> changes that improve dev experience and performance.
>
> For media related things:
> -  VideoFrame is a versatile tool that can be created from
> HTMLOrSVGImageElement, HTMLVideoElement, HTMLCanvasElement, ImageBitmap,
>  OffscreenCanvas without a copy. In a way this change extends
> variety of export formats for all of them.
> So lots of things can be exported to RGB bitmaps without a canvas now.
> -  AudioData has a way to be exported into different sampling formats.
>
>
>
> On Wed, May 1, 2024 at 9:41 AM Mike Taylor  wrote:
>
>> +1. Would you mind also filing gecko and webkit positions? I expect them
>> to be positive, given the informal signals you have in the spec PRs already
>> - but this also lets them know we're moving ahead with shipping. Thanks -
>> Mike
>> On 5/1/24 11:51 AM, Alex Russell wrote:
>>
>> hey Eugene,
>>
>> This is an exciting an useful addition! Have you looked into other
>> platform APIs that could benefit from being able to explicitly specify
>> intermediate format hinting and/or transformation? It's a place where (had
>> the TAG been consulted) I would have expected to see a larger chain of
>> additions to make this work in other areas, or at least a discussion of why
>> they aren't (or are?) being pursued. Have you looked into that?
>>
>> Best,
>>
>> Alex
>>
>> On Tuesday, April 30, 2024 at 3:51:01 PM UTC-7 Eugene Zemtsov wrote:
>>
>>> > Can you please request reviews for privacy, security, enterprise, etc
>>> in the chromestatus entry?
>>>
>>> Done
>>>
>>> On Mon, Apr 29, 2024 at 7:44 AM Mike Taylor 
>>> wrote:
>>>
 Can you please request reviews for privacy, security, enterprise, etc
 in the chromestatus entry?
 On 4/25/24 6:19 PM, 'Eugene Zemtsov' via blink-dev wrote:

 Contact emails ezemt...@google.com

 Explainer
 https://gist.github.com/Djuffin/9e2f98025ead49998524510cfeed8d33

 Specification https://www.w3.org/TR/webcodecs/#dom-videoframe-copyto

 Summary

 VideoFrame.copyTo() can convert pixel data to RGB pixel format
 Converting YUV video frames to RGB is often required for processing them in
 libraries like TensorFlow.js and OpenCV.js. Previously the only possible
 way to achieve this was rendering the frame on a canvas. Specifying
 VideoFrameCopyToOptions.format and VideoFrameCopyToOptions.colorSpace makes
 it possible to convert frames to RGB pixel formats by calling
 VideoFrame.copyTo() without having to use an extra canvas.

 Blink component Blink>Media>WebCodecs
 

 Initial public proposal https://github.com/w3c/webcodecs/issues/92

 TAG review N/A since the change is minor

 Risks


 Interoperability and Compatibility

 None


 *Gecko*: Positive (
 https://github.com/w3c/webcodecs/pull/754#pullrequestreview-2008590591)

 *WebKit*: Positive TPAC 2023. Media working group session.

 *Web developers*:
 https://github.com/w3c/webcodecs/issues/92#issuecomment-1594083978

 *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

 https://wpt.fyi/results/webcodecs videoFrame-copyTo-rgb.any.js


 Estimated milestones
 Shipping on desktop 126
 Shipping on Android 126

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

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

Re: [blink-dev] Running WebGPU on Amazon EC2 Windows instance

[wenhan chong]

Thanks François,
I am not able to follow the steps completely because they are using Linux 
instances while I am trying to run WebGPU on Windows Server 2022.
Nevertheless, I installed nvidia drivers and vulkan runtime for Windows but 
Chrome is still unable to detect the GPU.
Does Chrome on Windows Server support WebGPU out of the box?

On Monday 6 May 2024 at 22:24:21 UTC+8 François Beaufort wrote:

> https://developer.chrome.com/blog/supercharge-web-ai-testing is the first 
> part.
>
>
> On Mon, May 6, 2024 at 4:23 PM François Beaufort  
> wrote:
>
>> Hello Wen Han,
>> May I recommend 
>> https://developer.chrome.com/docs/web-platform/webgpu/colab-headless if 
>> you haven't read it yet?
>>
>> On Mon, May 6, 2024 at 4:20 PM wenhan chong  wrote:
>>
>>> Hi All,
>>>
>>> I am trying to run WebGPU on an Amazon EC2 Windows instance but I am 
>>> unable to get the browser to detect WebGPU. I have nvidia drivers and 
>>> chrome v124 installed on the instance but requestAdapter still fails for 
>>> WebGPU. I can render WebGL2 just fine. Are there any additional flags or 
>>> libraries I need to install to be able to use WebGPU on EC2?
>>>
>>> Regards,
>>> Wen Han
>>>
>>> -- 
>>> 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/6084010a-6302-4c1d-937d-d2c65ad45663n%40chromium.org
>>>  
>>> 
>>> .
>>>
>>

-- 
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/3dc4204e-b9cc-4461-ac41-58d06b4c9d1en%40chromium.org.

[blink-dev] Intent to Prototype: Link rel=payment to support push payments

['Junhui He' via blink-dev]

Contact emailsaneesh...@google.com, junhu...@google.com

Explainer
https://github.com/aneeshali/paymentlink/blob/main/docs/explainer.md

Summary

Adds support for  as a hint that the browser
should notify registered payment clients about a pending push payment. When
Blink encounters this HTML element, then it will send a message to the
browser to display the user's interface to ask the user if they would like
to invoke Google Pay to assist payments on this page.

Blink componentBlink>Payments


Motivation

This feature lets the browser assist users in push-based payment flows by
facilitating the transfer of payment information between the payment
provider (on the payee side) and the payment client (on the payer side).
The feature lays the foundation for payment integrators in streamlining
push-based payment flows, towards a consistent and low-friction user
experience.

Risks
Interoperability and Compatibility

We're not aware that anybody else uses payment link .

*Gecko*: No signal

*WebKit*: No signal

*Web developers*: No 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

Flag name on chrome://flags#enable-payment-link-detection

Finch feature name"EnablePaymentLinkDetection"

Requires code in //chrome?True - Detection of the payment link does not
need coding //chrome, but code in //chrome will eventually be required to
invoke Google Pay APIs.

Tracking bughttps://crbug.com/1477049

Estimated milestones

M132

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5198846820352000?gate=5076188191522816

-- 
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/CAAgNxUspmNSeL1F6hUziTMOkSusPPZS0D6B-AWfpKctiN7JGvQ%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Protected Audience ads reporting - allow cross-origin subframes to send reportEvent() beacons

[Mike Taylor]

On 5/8/24 11:30 AM, 'Liam Brady' via blink-dev wrote:


Contact emails

lbr...@google.com , shivani...@chromium.org 
, jkar...@chromium.org 




Explainer(s)

https://github.com/WICG/turtledove/pull/1134 




Spec(s)

https://github.com/WICG/fenced-frame/pull/152 




Summary

Ad frames (both fenced frames and urn-iframes) created through a 
Protected Audience auction, as well as their same-origin nested 
iframes, are allowed to call reportEvent() API 
to 
send event-level reports. It's also important for third-parties on 
Protected Audience-created ads to have the same measurement and 
reporting capabilities for spam detection, brand safety, and 
measurement verification. However, the API as it exists currently has 
a same-origin child iframe restriction which poses a complication as 
described below.



If an ad buyer wins an ad auction and its ad frame is displayed on a 
page, it might choose to embed a subframe that points to a third-party 
server that hosts the actual ad instead. With this use case, and with 
the current state of the reportEvent() API, the actual ad's document 
cannot directly call reportEvent() the way that its embedder can since 
the document is in a cross-origin nested iframe. Instead, it has to 
get its embedder to actually send the beacon by letting the embedder 
know via a postMessage. This will not be an ergonomic solution for 
this use case.



With this change, a cross-origin subframe can opt in to sending 
reportEvent() beacons using its ancestor's reporting metadata by 
calling reportEvent() with the parameter crossOriginExposed=true. This 
is the same syntax as is currently used by the main render URL frame 
to opt in to sending cross-origin automatic beacons with data (this 
means the FenceEvent IDL will stay the same).



The main ad render URL frame will opt in with a new 
"Allow-Cross-Origin-Event-Reporting" response header. Its valid values 
will be true and false, and will default to false when omitted. This 
will not be required for documents that are same-origin to the 
FencedFrameConfig's mapped url.


Can you clarify what the type is for this new header? It reads as if 
you're adding a String Item that looks like a boolean, rather than a 
Boolean Item. Is that correct? It doesn't seem to be actually defined in 
the spec.


(I filed https://github.com/WICG/fenced-frame/issues/158 for that.)



This is a convenience change (not privacy impacting), as it's already 
possible (but cumbersome) for the third-party to postMessage the 
parent frame to send the report on their behalf. For security reasons, 
the proposal requires opt-ins from both the main ad frame and the 
cross-origin iframe.



Blink component

Blink>FencedFrames 




TAG reviews and status

Fenced frames existing TAG review appended with these spec changes 
https://github.com/w3ctag/design-reviews/issues/838# 




Link to Origin Trial feedback summary

No Origin Trial performed


Is this feature supported on all six Blink platforms (Windows, Mac, 
Linux, Chrome OS, Android, and Android WebView)?


Supported on all the above platforms except Android WebView.


Debuggability

Additional debugging capabilities are not necessary for these feature 
changes.



Risks


Compatibility

This is an added functionality and is backward compatible.


Interoperability

There are no interoperability risks as no other browsers have decided 
to implement these features yet. We have not received any standards 
positions from Mozilla 
or Webkit 
.



Is this feature fully tested by web-platform-tests 
? 
Link to test suite results from wpt.fyi .


Yes. New reportEvent() beacon tests have been added to test 
cross-origin beacons.


fence-report-event-cross-origin-content-initiated.https.html (test 
) 
(results 
)


fence-report-event-cross-origin-nested-urn-iframe.https.html (test 
) 
(results 
)

Re: [blink-dev] Re: Intent to Ship: Document picture-in-picture: propagate user activation

[Mike Taylor]

LGTM3

On 5/8/24 11:56 AM, Daniel Bratell wrote:


LGTM2

/Daniel

On 2024-05-08 17:11, Yoav Weiss (@Shopify) wrote:

LGTM1

On Tuesday, May 7, 2024 at 11:33:01 PM UTC+2 Tommy Steimel wrote:


Contact emails

stei...@chromium.org, liber...@chromium.org



Explainer

None


Specification

https://github.com/WICG/document-picture-in-picture/pull/117



Design docs



https://docs.google.com/document/d/1vtjK3iMEAjcfDCu-qZOYg2zAtTbhohmCX77T1Eu3usQ/edit?usp=sharing




Summary

This makes user activations in a document picture-in-picture
window usable inside its opener window and vice versa. This makes
it more ergonomic to use user-activation-gated APIs, since often
event handlers in the document picture-in-picture window are
actually run in the opener's context, so the opener's context
needs access to the user gesture.



Blink component

Blink>Media>PictureInPicture




TAG review

https://github.com/w3ctag/design-reviews/issues/798#issuecomment-2096837171




TAG review status

Pending


Risks



Interoperability and Compatibility

None



/Gecko/: No signal

(https://github.com/mozilla/standards-positions/issues/670#issuecomment-2096824367

)

/WebKit/: No signal

(https://github.com/WebKit/standards-positions/issues/41#issuecomment-2096824691

)

/Web developers/: No signals

/Other signals/:


Ergonomics

This should improve the ergnomics of user-activation-gated APIs
in document picture-in-picture windows, as the website no longer
needs to ensure that the user gesture occurred in the same
context as the code that is calling the API.



Activation

N/A



Security

One potential risk is that the website could use the same gesture
as two gestures (by using it in the opener and in the
picture-in-picture window). We mitigate this by ensuring that
consuming user activation in one uses it in the other.



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

N/A



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

No

Document picture-in-picture is only available on desktop platforms



Is this feature fully tested by web-platform-tests

?

Yes

document-picture-in-picture/propagate-user-activation-from-opener.https.html
document-picture-in-picture/propagate-user-activation-to-opener.https.html



Flag name on chrome://flags

document-picture-in-picture-user-activation


Finch feature name

DocumentPictureInPictureUserActivation


Requires code in //chrome?

False


Tracking bug

https://issues.chromium.org/331246719



Sample links


https://steimelchrome.github.io/document-pip/user-gesture.html



Estimated milestones

Shipping on desktop 126



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

N/A


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5185710702460928?gate=5078256593403904



Links to previous Intent discussions

Intent to prototype:

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAE-AwApczWrtoZNMqtAJx-%2BNAxVF9Kqim2h1HBrAD3ukXTKgWA%40mail.gmail.com

Re: [blink-dev] Intent to Ship: Tabbed web apps

[Brett Wilson]

On Wed, May 8, 2024 at 8:39 AM Alex Russell 
wrote:

> I'm happy for this to be CrOS first, but would like to unpack Brett's
> statement above a bit. If we (MSFT) were to polish this up for Windows,
> would patches for that be accepted?
>

I can't speak for the browser team. But my current understanding is that
the browser team likes this in principle but doesn't prioritize it high
enough to work on it right now (this is a correction from my previous
assertion). So I'm pretty sure patches enabling this for other platforms
would be accepted.

Brett

-- 
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/CABiGVV-Zeyv3Rez%2BPQ%2B%2BfW4ihpRCwnnGN2HNxOyXTA7_uWehzw%40mail.gmail.com.

[blink-dev] Re: Intent to Ship: Protected Audience ads reporting - allow cross-origin subframes to send reportEvent() beacons

['Eli Grey' via blink-dev]

This change would impact the ability of first parties to regulate and 
prevent reportEvent beacons. Although this requires mutual opt-in, I expect 
scenarios to eventually come up where a site owner wants to allow 
cross-origin reportEvent only for certain origins.

On Wednesday, May 8, 2024 at 8:30:58 AM UTC-7 lbr...@google.com wrote:

> Contact emails
>
> lbr...@google.com, shiva...@chromium.org, jka...@chromium.org
>
> Explainer(s)
>
> https://github.com/WICG/turtledove/pull/1134
>
> Spec(s)
>
> https://github.com/WICG/fenced-frame/pull/152
>
> Summary
>
> Ad frames (both fenced frames and urn-iframes) created through a Protected 
> Audience auction, as well as their same-origin nested iframes, are allowed 
> to call reportEvent() API 
> 
>  
> to send event-level reports. It's also important for third-parties on 
> Protected Audience-created ads to have the same measurement and reporting 
> capabilities for spam detection, brand safety, and measurement 
> verification. However, the API as it exists currently has a same-origin 
> child iframe restriction which poses a complication as described below.
>
> If an ad buyer wins an ad auction and its ad frame is displayed on a page, 
> it might choose to embed a subframe that points to a third-party server 
> that hosts the actual ad instead. With this use case, and with the current 
> state of the reportEvent() API, the actual ad's document cannot directly 
> call reportEvent() the way that its embedder can since the document is in a 
> cross-origin nested iframe. Instead, it has to get its embedder to actually 
> send the beacon by letting the embedder know via a postMessage. This will 
> not be an ergonomic solution for this use case.
>
> With this change, a cross-origin subframe can opt in to sending 
> reportEvent() beacons using its ancestor's reporting metadata by calling 
> reportEvent() with the parameter crossOriginExposed=true. This is the same 
> syntax as is currently used by the main render URL frame to opt in to 
> sending cross-origin automatic beacons with data (this means the FenceEvent 
> IDL will stay the same).
>
> The main ad render URL frame will opt in with a new 
> "Allow-Cross-Origin-Event-Reporting" response header. Its valid values will 
> be true and false, and will default to false when omitted. This will not be 
> required for documents that are same-origin to the FencedFrameConfig's 
> mapped url.
>
> This is a convenience change (not privacy impacting), as it's already 
> possible (but cumbersome) for the third-party to postMessage the parent 
> frame to send the report on their behalf. For security reasons, the 
> proposal requires opt-ins from both the main ad frame and the cross-origin 
> iframe.
>
> Blink component
>
> Blink>FencedFrames 
> 
>
> TAG reviews and status
>
> Fenced frames existing TAG review appended with these spec changes 
> https://github.com/w3ctag/design-reviews/issues/838# 
> 
>
> Link to Origin Trial feedback summary
>
> No Origin Trial performed
>
> Is this feature supported on all six Blink platforms (Windows, Mac, Linux, 
> Chrome OS, Android, and Android WebView)?
>
> Supported on all the above platforms except Android WebView.
>
> Debuggability
>
> Additional debugging capabilities are not necessary for these feature 
> changes.
>
> Risks
>
> Compatibility
>
> This is an added functionality and is backward compatible.
>
> Interoperability
>
> There are no interoperability risks as no other browsers have decided to 
> implement these features yet. We have not received any standards positions 
> from Mozilla  
> or Webkit .
>
> Is this feature fully tested by web-platform-tests 
> ?
>  
> Link to test suite results from wpt.fyi. 
>
> Yes. New reportEvent() beacon tests have been added to test cross-origin 
> beacons.
>
> fence-report-event-cross-origin-content-initiated.https.html (test 
> )
>  
> (results 
> 
> )
>
> fence-report-event-cross-origin-nested-urn-iframe.https.html (test 
> )
>  
> (results 
> 
> )
>
> fence-report-event-cross-origin-nested.https.html (test 

Re: [blink-dev] Re: Intent to Ship: Document picture-in-picture: propagate user activation

[Daniel Bratell]

LGTM2

/Daniel

On 2024-05-08 17:11, Yoav Weiss (@Shopify) wrote:

LGTM1

On Tuesday, May 7, 2024 at 11:33:01 PM UTC+2 Tommy Steimel wrote:


Contact emails

stei...@chromium.org, liber...@chromium.org



Explainer

None


Specification

https://github.com/WICG/document-picture-in-picture/pull/117



Design docs



https://docs.google.com/document/d/1vtjK3iMEAjcfDCu-qZOYg2zAtTbhohmCX77T1Eu3usQ/edit?usp=sharing




Summary

This makes user activations in a document picture-in-picture
window usable inside its opener window and vice versa. This makes
it more ergonomic to use user-activation-gated APIs, since often
event handlers in the document picture-in-picture window are
actually run in the opener's context, so the opener's context
needs access to the user gesture.



Blink component

Blink>Media>PictureInPicture




TAG review

https://github.com/w3ctag/design-reviews/issues/798#issuecomment-2096837171




TAG review status

Pending


Risks



Interoperability and Compatibility

None



/Gecko/: No signal

(https://github.com/mozilla/standards-positions/issues/670#issuecomment-2096824367

)

/WebKit/: No signal

(https://github.com/WebKit/standards-positions/issues/41#issuecomment-2096824691

)

/Web developers/: No signals

/Other signals/:


Ergonomics

This should improve the ergnomics of user-activation-gated APIs in
document picture-in-picture windows, as the website no longer
needs to ensure that the user gesture occurred in the same context
as the code that is calling the API.



Activation

N/A



Security

One potential risk is that the website could use the same gesture
as two gestures (by using it in the opener and in the
picture-in-picture window). We mitigate this by ensuring that
consuming user activation in one uses it in the other.



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

N/A



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

No

Document picture-in-picture is only available on desktop platforms



Is this feature fully tested by web-platform-tests

?

Yes

document-picture-in-picture/propagate-user-activation-from-opener.https.html
document-picture-in-picture/propagate-user-activation-to-opener.https.html



Flag name on chrome://flags

document-picture-in-picture-user-activation


Finch feature name

DocumentPictureInPictureUserActivation


Requires code in //chrome?

False


Tracking bug

https://issues.chromium.org/331246719



Sample links


https://steimelchrome.github.io/document-pip/user-gesture.html



Estimated milestones

Shipping on desktop 126



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

N/A


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5185710702460928?gate=5078256593403904



Links to previous Intent discussions

Intent to prototype:

https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAE-AwApczWrtoZNMqtAJx-%2BNAxVF9Kqim2h1HBrAD3ukXTKgWA%40mail.gmail.com



This intent message was generated 

[blink-dev] Re: Intent to Ship: WebRTC encoded transform - Constructor with custom Metadata (originally Modify Metadata functions)

[Alex Russell]

Hey Guido,

This is a cool feature! The Milestones section shows that an OT was run; is 
there a summary someplace of what we learned from the OT?

Best,

Alex

On Thursday, May 2, 2024 at 4:40:31 AM UTC-7 Guido Urdaneta wrote:

> Contact emails...@chromium.org, gui...@chromium.org, agpa...@chromium.org
>
> Explainer
> https://github.com/guidou/webrtc-extensions/blob/main/constructor-explainer.md
>
> Specification
> https://w3c.github.io/webrtc-encoded-transform/#dom-rtcencodedvideoframe-constructor
> https://w3c.github.io/webrtc-encoded-transform/#dom-rtcencodedaudioframe-constructor
>
> Summary
>
> Allow WebRTC Encoded Transform API to create encoded audio and video 
> frames specifying custom metadata. This is achieved by introducing 
> constructors for encoded frames that take the original frame and custom 
> metadata as input. This supports use cases that involve manipulation of not 
> only the payload of encoded video / audio frames but also its metadata. 
> Some examples: * Changing the mime type of the frame if the transform 
> changes the type of the payload * Forwarding of media to a new peer 
> connection set up to use different metadata values * Altering the timestamp 
> of a frame to introduce a delay 
> Use cases: https://w3c.github.io/webrtc-nv-use-cases/#live-encoded-media 
> https://w3c.github.io/webrtc-nv-use-cases/#stored-encoded-media 
> https://w3c.github.io/webrtc-nv-use-cases/#auction Issue link: 
> https://github.com/w3c/webrtc-nv-use-cases/issues/77
>
> This change has consensus in the WebRTC Working Group and has been merged 
> into the WebRTC Encoded Transform spec.
>
> Blink componentBlink>WebRTC 
> 
>
> TAG reviewTAG review request for this specific change: 
> https://github.com/w3ctag/design-reviews/issues/942 The original version 
> of the full spec was reviewed by TAG here: 
> https://github.com/w3ctag/design-reviews/issues/531
>
> TAG review statusPending
>
> Chromium Trial NameRTCEncodedFrameSetMetadata
>
> Origin Trial documentation link
> https://github.com/palak8669/webrtc-encoded-transform/blob/create-encoded-explainer/create-encoded-explainer.md
>
> WebFeature UseCounter nameRTCEncodedFrameSetMetadata
>
> Risks
>
>
> Interoperability and Compatibility
>
> Interoperability risk: There is always the risk that other browsers will 
> not implement this feature. This risk is mitigated by alignment across 
> browser vendors in the W3C WebRTC Working Group around the spec. 
> Compatibility risk: This is a new feature intended to support new use 
> cases. It introduces no breaking changes, so we do not expect any 
> compatibility issues. 
>
> *Gecko*: No signal (
> https://github.com/mozilla/standards-positions/issues/1009) During WebRTC 
> WG meetings, Mozilla has shown positive signals and agreed with merging the 
> PR in the main spec. See the exchange in 
> https://github.com/w3c/webrtc-encoded-transform/pull/223
>
> *WebKit*: Positive (
> https://github.com/WebKit/standards-positions/issues/334) 
> Marked as "Invalid" in the position request because this is a small change 
> and the position was addressed in the PR review. The comments from WebKit 
> in the PR review and during WebRTC WG meetings are positive and they have 
> agreed with merging the PR in the main spec. See the exchange in 
> https://github.com/w3c/webrtc-encoded-transform/pull/223
>
> *Web developers*: Positive
>
> *Other signals*:
>
> Ergonomics
>
> This feature is an extension to WebRTC Encoded Transform, which itself is 
> an extension to WebRTC/RTCPeerConnection.
>
>
> Activation
>
> No significant risks identified.
>
>
> Security
>
> No new security risks identified.
>
>
> 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?
>
> No
>
>
> Debuggability
>
> N/A
>
>
> 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/webrtc-encoded-transform/tentative/RTCEncodedAudioFrame-metadata.https.html?label=master=experimental
>  
> https://wpt.fyi/results/webrtc-encoded-transform/tentative/RTCEncodedVideoFrame-metadata.https.html?label=master=experimental
>  
>
>
> Flag name on chrome://flags
>
> Finch feature nameRTCEncodedFrameSetMetadata
>
> Non-finch justification
>
> Guarded by a Blink RuntimeEnabledFeature.
>
>
> Requires code in //chrome?False
>
> Tracking bughttps://issues.chromium.org/issues/40248396
>
> Estimated milestones
> Shipping on desktop 126
> Origin trial desktop first 118
> Origin trial desktop last 126
> Origin trial extension 1 end milestone 126
> Shipping on Android 126
> OriginTrial Android last 126
> OriginTrial Android first 118

Re: [blink-dev] Intent to Ship: Tabbed web apps

[Alex Russell]

I'm happy for this to be CrOS first, but would like to unpack Brett's 
statement above a bit. If we (MSFT) were to polish this up for Windows, 
would patches for that be accepted?

On Tuesday, May 7, 2024 at 6:25:26 PM UTC-7 Matt Giuca wrote:

> Hi Yoav,
>
> The API was specifically designed to allow developers to customize the 
> fallback, so the short answer is "whatever fallback they want".
>
> Since the "display" Manifest member only allows for a single string, 
> adding a new value there would break backwards compatibility for any site 
> that used the new value. That is why we do not allow "tabbed" and other new 
> display modes in that member; they can only be used in the new 
> "display_override" member which is a list of display modes representing a 
> developer-supplied fallback chain, with the final fallback being the value 
> of the old "display" member.
>
> So developers can generally choose between two configurations:
>
>1. "display_override": ["tabbed"], "display": "standalone"
>2. "display_override": ["tabbed"], "display": "browser"
>
> If they choose #1, non-supported platforms will fall back to a standalone 
> non-tabbed window (feeling like an app but not having a tabbed experience). 
> If they choose #2, non-supported platforms will fall back to not having a 
> separate window and just opening the content in the browser (giving the 
> user a tabbed experience but not feeling like an app).
>
> We would recommend that developers fall back to whatever they are already 
> using. That way, tabbed mode is an additive experience (currently only on 
> ChromeOS but automatically upgrading to that experience on any platform 
> that supports it in the future), with a graceful degradation to the status 
> quo.
>
> Therefore, we don't think cross platform support for this feature is 
> necessary, though of course it has been designed for this as a future 
> possibility. Also there is nothing ChromeOS-specific about this design, as 
> Marijn pointed out, it just hasn't been prioritized by the engineering team 
> outside of ChromeOS.
>
> Regards
>
> Matt
>
> On Tue, 7 May 2024 at 19:24, Yoav Weiss (@Shopify)  
> wrote:
>
>> Can you elaborate on the cross-platform story here? What kind of fallback 
>> do we expect developers to use in non-supporting platforms?
>>
>> On Tue, May 7, 2024 at 12:34 AM Marijn Kruisselbrink  
>> wrote:
>>
>>> I don't think there are major technical reasons, no. With some rough 
>>> edges the flagged implementation should more or less work on other 
>>> desktop platforms as well. My understanding is that this is largely a 
>>> product choice and a choice not to prioritize the remaining engineering 
>>> needed to clean up the rough edges on other desktop platforms.
>>>
>>> On Mon, May 6, 2024 at 3:29 PM Daniel Herr  
>>> wrote:
>>>
 May I ask why? I've tried out the flagged implementation on Chrome OS, 
 and I think it is a pretty nice UI paradigm. I don't see any technical 
 reason it shouldn't be available on other platforms.

 On Monday, May 6, 2024 at 10:30:58 AM UTC-4 Brett Wilson wrote:

> On Mon, May 6, 2024 at 3:02 AM Yoav Weiss (@Shopify) <
> yoav...@chromium.org> wrote:
>
>>
>>
>> On Fri, May 3, 2024 at 7:28 PM Brett Wilson  
>> wrote:
>>
>>> Contact emailsbre...@chromium.org, alanc...@chromium.org, 
>>> mgi...@chromium.org, loub...@google.com
>>>
>>> Explainer
>>> https://github.com/WICG/manifest-incubations/blob/gh-pages/tabbed-mode-explainer.md
>>>
>>> Specificationhttps://wicg.github.io/manifest-incubations/#dfn-tabbed
>>>
>>> Summary
>>>
>>> Allow web app windows to have a tab strip. This adds a new display 
>>> mode "tabbed" and a new manifest field to allow customizations to the 
>>> tab 
>>> strip.
>>>
>>>
>>> Blink componentBlink>AppManifest 
>>> 
>>>
>>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/841
>>>
>>> TAG review statusIssues addressed
>>>
>>> Chromium Trial NameWebAppTabStrip
>>>
>>> Link to origin trial feedback summary
>>> https://github.com/WICG/manifest-incubations/issues
>>>
>>> Origin Trial documentation link
>>> https://github.com/WICG/manifest-incubations/blob/gh-pages/tabbed-mode-explainer.md
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>>
>>>
>>> *Gecko*: Defer (
>>> https://github.com/mozilla/standards-positions/issues/811)
>>>
>>> *WebKit*: No signal (
>>> https://github.com/WebKit/standards-positions/issues/195)
>>>
>>> *Web developers*: Positive (
>>> https://github.com/w3c/manifest/issues/737)
>>>
>>> *Other signals*:
>>>
>>> WebView application risks
>>>
>>> Does this intent deprecate or change behavior of existing APIs, such 
>>> that it has 

[blink-dev] Intent to Ship: Protected Audience ads reporting - allow cross-origin subframes to send reportEvent() beacons

['Liam Brady' via blink-dev]

Contact emails

lbr...@google.com, shivani...@chromium.org, jkar...@chromium.org

Explainer(s)

https://github.com/WICG/turtledove/pull/1134

Spec(s)

https://github.com/WICG/fenced-frame/pull/152

Summary

Ad frames (both fenced frames and urn-iframes) created through a Protected 
Audience auction, as well as their same-origin nested iframes, are allowed 
to call reportEvent() API 

 
to send event-level reports. It's also important for third-parties on 
Protected Audience-created ads to have the same measurement and reporting 
capabilities for spam detection, brand safety, and measurement 
verification. However, the API as it exists currently has a same-origin 
child iframe restriction which poses a complication as described below.

If an ad buyer wins an ad auction and its ad frame is displayed on a page, 
it might choose to embed a subframe that points to a third-party server 
that hosts the actual ad instead. With this use case, and with the current 
state of the reportEvent() API, the actual ad's document cannot directly 
call reportEvent() the way that its embedder can since the document is in a 
cross-origin nested iframe. Instead, it has to get its embedder to actually 
send the beacon by letting the embedder know via a postMessage. This will 
not be an ergonomic solution for this use case.

With this change, a cross-origin subframe can opt in to sending 
reportEvent() beacons using its ancestor's reporting metadata by calling 
reportEvent() with the parameter crossOriginExposed=true. This is the same 
syntax as is currently used by the main render URL frame to opt in to 
sending cross-origin automatic beacons with data (this means the FenceEvent 
IDL will stay the same).

The main ad render URL frame will opt in with a new 
"Allow-Cross-Origin-Event-Reporting" response header. Its valid values will 
be true and false, and will default to false when omitted. This will not be 
required for documents that are same-origin to the FencedFrameConfig's 
mapped url.

This is a convenience change (not privacy impacting), as it's already 
possible (but cumbersome) for the third-party to postMessage the parent 
frame to send the report on their behalf. For security reasons, the 
proposal requires opt-ins from both the main ad frame and the cross-origin 
iframe.

Blink component

Blink>FencedFrames 


TAG reviews and status

Fenced frames existing TAG review appended with these spec changes 
https://github.com/w3ctag/design-reviews/issues/838# 


Link to Origin Trial feedback summary

No Origin Trial performed

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, 
Chrome OS, Android, and Android WebView)?

Supported on all the above platforms except Android WebView.

Debuggability

Additional debugging capabilities are not necessary for these feature 
changes.

Risks

Compatibility

This is an added functionality and is backward compatible.

Interoperability

There are no interoperability risks as no other browsers have decided to 
implement these features yet. We have not received any standards positions 
from Mozilla  or 
Webkit .

Is this feature fully tested by web-platform-tests 
?
 
Link to test suite results from wpt.fyi. 

Yes. New reportEvent() beacon tests have been added to test cross-origin 
beacons.

fence-report-event-cross-origin-content-initiated.https.html (test 
)
 
(results 

)

fence-report-event-cross-origin-nested-urn-iframe.https.html (test 
)
 
(results 

)

fence-report-event-cross-origin-nested.https.html (test 
)
 
(results 

)

fence-report-event-cross-origin-no-embedder-opt-in.https.html (test 
)
 
(results 

Re: [blink-dev] Intent to Ship: CSSPageRule to inherit from CSSGroupingRule

[Mike Taylor]

On 5/8/24 3:37 AM, Morten Stenshorne wrote:



Interoperability and Compatibility

Low risk. The one possible issue is if an author uses "instanceof 
CSSGroupingRule" or "instanceof CSSRule" with a page rule object and 
makes incorrect assumptions based on that. However, given that this is 
already shipping in Firefox (and also that in Firefox, even 
CSSStyleRule inherits from CSSGroupingRule, as the spec says - whereas 
Blink still doesn't), the risk should be very low.


I agree the risk is likely very low, or contained to just a few 
sites/applications - have you done any investigation to try to find any 
problematic code examples that you mention (via GitHub search or 
HTTPArchive)?



/Gecko/: Shipped/Shipping 
(https://bugzilla.mozilla.org/show_bug.cgi?id=1868215)
Noting that the patch should ship to Firefox release channel (126) in 
about a week, per https://whattrainisitnow.com/calendar/.


/WebKit/: No signal
Can we request a signal? Or do we have any other indications about their 
intentions here?


/Web developers/: No signals

/Other signals/:


--
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/ba66dbb0-d472-4acd-97f2-a3502c5b74cb%40chromium.org.

[blink-dev] Re: Intent to Ship: Document picture-in-picture: propagate user activation

[Yoav Weiss (@Shopify)]

LGTM1

On Tuesday, May 7, 2024 at 11:33:01 PM UTC+2 Tommy Steimel wrote:

> Contact emailsstei...@chromium.org, liber...@chromium.org
>
> ExplainerNone
>
> Specificationhttps://github.com/WICG/document-picture-in-picture/pull/117
>
> Design docs
>
> https://docs.google.com/document/d/1vtjK3iMEAjcfDCu-qZOYg2zAtTbhohmCX77T1Eu3usQ/edit?usp=sharing
>
> Summary
>
> This makes user activations in a document picture-in-picture window usable 
> inside its opener window and vice versa. This makes it more ergonomic to 
> use user-activation-gated APIs, since often event handlers in the document 
> picture-in-picture window are actually run in the opener's context, so the 
> opener's context needs access to the user gesture.
>
>
> Blink componentBlink>Media>PictureInPicture 
> 
>
> TAG review
> https://github.com/w3ctag/design-reviews/issues/798#issuecomment-2096837171
>
> TAG review statusPending
>
> Risks
>
>
> Interoperability and Compatibility
>
> None
>
>
> *Gecko*: No signal (
> https://github.com/mozilla/standards-positions/issues/670#issuecomment-2096824367
> )
>
> *WebKit*: No signal (
> https://github.com/WebKit/standards-positions/issues/41#issuecomment-2096824691
> )
>
> *Web developers*: No signals
>
> *Other signals*:
>
> Ergonomics
>
> This should improve the ergnomics of user-activation-gated APIs in 
> document picture-in-picture windows, as the website no longer needs to 
> ensure that the user gesture occurred in the same context as the code that 
> is calling the API.
>
>
> Activation
>
> N/A
>
>
> Security
>
> One potential risk is that the website could use the same gesture as two 
> gestures (by using it in the opener and in the picture-in-picture window). 
> We mitigate this by ensuring that consuming user activation in one uses it 
> in the other.
>
>
> 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
>
> N/A
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac, 
> Linux, ChromeOS, Android, and Android WebView)?No
>
> Document picture-in-picture is only available on desktop platforms
>
>
> Is this feature fully tested by web-platform-tests 
> 
> ?Yes
>
> document-picture-in-picture/propagate-user-activation-from-opener.https.html 
> document-picture-in-picture/propagate-user-activation-to-opener.https.html
>
>
> Flag name on chrome://flagsdocument-picture-in-picture-user-activation
>
> Finch feature nameDocumentPictureInPictureUserActivation
>
> Requires code in //chrome?False
>
> Tracking bughttps://issues.chromium.org/331246719
>
> Sample links
> https://steimelchrome.github.io/document-pip/user-gesture.html
>
> Estimated milestones
> Shipping on desktop 126
>
> 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).
> N/A
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5185710702460928?gate=5078256593403904
>
> Links to previous Intent discussionsIntent to prototype: 
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAE-AwApczWrtoZNMqtAJx-%2BNAxVF9Kqim2h1HBrAD3ukXTKgWA%40mail.gmail.com
>
> This intent message was generated by Chrome Platform Status 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8e5d025d-9351-47d4-a79a-f7f23c88851dn%40chromium.org.

[blink-dev] Intent to Ship: CSSPageRule to inherit from CSSGroupingRule

[Morten Stenshorne]

Contact emailsmsten...@chromium.org

ExplainerNone

Specificationhttps://drafts.csswg.org/cssom/#the-csspagerule-interface

Summary

Let CSSPageRule inherit from CSSGroupingRule instead of CSSRule. The spec
[1] says that the CSSPageRule interface should inherit from
CSSGroupingRule, but Blink inherits from CSSRule instead. In order to
support @page margins (CSSMarginRule), CSSPageRule needs to support child
rules. [1] https://drafts.csswg.org/cssom/#the-csspagerule-interface [2]
https://drafts.csswg.org/css-page-3/#syntax-page-selector


Blink componentBlink>CSS


TAG reviewNone

TAG review statusNot applicable

Risks


Interoperability and Compatibility

Low risk. The one possible issue is if an author uses "instanceof
CSSGroupingRule" or "instanceof CSSRule" with a page rule object and makes
incorrect assumptions based on that. However, given that this is already
shipping in Firefox (and also that in Firefox, even CSSStyleRule inherits
from CSSGroupingRule, as the spec says - whereas Blink still doesn't), the
risk should be very low.


*Gecko*: Shipped/Shipping (
https://bugzilla.mozilla.org/show_bug.cgi?id=1868215)

*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

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

Flag name on chrome://flagsNone

Finch feature nameNone

Non-finch justification

There's no way to make such a change behind a runtime feature flag, so this
will just have to ship when the code change lands. In the worst case, it
will have to be reverted.


Requires code in //chrome?False

Tracking bughttps://issues.chromium.org/issues/324827379

Estimated milestones
Shipping on desktop 126
Shipping on Android 126

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/5218866421825536?gate=6703446991568896

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/CAKWZFm6A_ym0LTCu88g0-3Z3VgCR61aR9%3Do1qe6sNYpGGOckdg%40mail.gmail.com.