Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: Clipboard API: Svg

['Anupam Snigdha' via blink-dev]

The exact steps of the sanitization process isn't specified anywhere since it's 
very fluid and also subject to change based on the outcome of the Sanitizer API 
proposal. Since the HTML format already uses this sanitizer, we decided to use 
it for SVG format as well. This was also proposed by the security team: 
https://docs.google.com/document/d/1jq8QSCQRdNy99rnPusmW8is62c22PVuq-Sk-tMT2tRk/edit?disco=GzUW4fQ

From: Yoav Weiss (@Shopify) 
Sent: Tuesday, February 27, 2024 1:53 PM
To: Anupam Snigdha 
Cc: Daniel Bratell ; Chris Harrelson 
; Thomas Steiner ; Evan Stade 
; Anupam Snigdha ; 一丝 
; blink-dev ; sligh...@chromium.org 
; svo...@gmail.com ; 
pwn...@chromium.org ; Marijn Kruisselbrink 
; huang...@chromium.org ; 
mk...@chromium.org ; Joshua Bell ; 
christin...@chromium.org ; etiennen...@chromium.org 
; Sanket Joshi (EDGE) 
Subject: Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: Clipboard API: Svg



On Tue, Feb 27, 2024 at 10:40 PM Anupam Snigdha 
mailto:sni...@microsoft.com>> wrote:
We're using the same sanitizer that HTML format uses to produce a fragment with 
styles inlined. This is also the same sanitization process used in paste 
operation(ctrl+V).

OK, so that's the one specified in 
https://github.com/w3c/clipboard-apis/issues/150?


From: Yoav Weiss (@Shopify) 
mailto:yoavwe...@chromium.org>>
Sent: Tuesday, February 27, 2024 1:30 PM
To: Anupam Snigdha mailto:sni...@microsoft.com>>
Cc: Daniel Bratell mailto:bratel...@gmail.com>>; Chris 
Harrelson mailto:chris...@chromium.org>>; Thomas Steiner 
mailto:to...@google.com>>; Evan Stade 
mailto:est...@chromium.org>>; Anupam Snigdha 
mailto:snianu.micros...@gmail.com>>; 一丝 
mailto:yio...@gmail.com>>; blink-dev 
mailto:blink-dev@chromium.org>>; 
sligh...@chromium.org 
mailto:slightly...@chromium.org>>; 
svo...@gmail.com 
mailto:s...@voisen.org>>; 
pwn...@chromium.org 
mailto:pwn...@chromium.org>>; Marijn Kruisselbrink 
mailto:m...@chromium.org>>; 
huang...@chromium.org 
mailto:huangdar...@chromium.org>>; 
mk...@chromium.org 
mailto:mk...@chromium.org>>; Joshua Bell 
mailto:jsb...@chromium.org>>; 
christin...@chromium.org 
mailto:christin...@chromium.org>>; 
etiennen...@chromium.org 
mailto:etiennen...@chromium.org>>; Sanket Joshi 
(EDGE) mailto:sa...@microsoft.com>>
Subject: Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: Clipboard API: Svg



On Tue, Feb 27, 2024 at 10:18 PM Anupam Snigdha 
mailto:sni...@microsoft.com>> wrote:
 I noticed that the tests here are marked as "tentative". Is the sanitizer part 
of this specified?
Since there is no consensus on the clipboard sanitization, the tests are marked 
as tentative for now. We had 
discussions 
 in the past to standardize 
the sanitization process (in the context of HTML), but were not able to get 
consensus

Oh my..

While consensus does seem elusive in this case, do you think it'd be possible 
to specify what we're shipping here, even if we can't standardize it right away?

from other browser vendors.

With the new Sanitizer 
API, hopefully we can 
standardize the sanitization process and make it consistent for all formats in 
the clipboard.


From: Yoav Weiss (@Shopify) 
mailto:yoavwe...@chromium.org>>
Sent: Tuesday, February 27, 2024 1:06 PM
To: Daniel Bratell mailto:bratel...@gmail.com>>
Cc: Chris Harrelson mailto:chris...@chromium.org>>; 
Anupam Snigdha mailto:sni...@microsoft.com>>; Thomas 
Steiner mailto:to...@google.com>>; Evan Stade 
mailto:est...@chromium.org>>; Anupam Snigdha 
mailto:snianu.micros...@gmail.com>>; 一丝 
mailto:yio...@gmail.com>>; blink-dev 
mailto:blink-dev@chromium.org>>; 
sligh...@chromium.org 
mailto:slightly...@chromium.org>>; 
svo...@gmail.com 
mailto:s...@voisen.org>>; 
pwn...@chromium.org 
mailto:pwn...@chromium.org>>; Marijn Kruisselbrink 
mailto:m...@chromium.org>>; 
huang...@chromium.org 
mailto:huangdar...@chromium.org>>; 
mk...@chromium.org 
mailto:mk...@chromium.org>>; Joshua Bell 
mailto:jsb...@chromium.org>>; 
christin...@chromium.org 
mailto:christin...@chromium.org>>; 
etiennen...@chromium.org 
mailto:etiennen...@chromium.org>>; Sanket Joshi 
(EDGE) mailto:sa...@microsoft.com>>
Subject: Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: Clipboard API: Svg


On Fri, Feb 23, 2024 at 7:40 PM Daniel Bratell 
mailto:bratel...@gmail.com>> wrote

Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: Clipboard API: Svg

[Yoav Weiss (@Shopify)]

On Tue, Feb 27, 2024 at 10:40 PM Anupam Snigdha 
wrote:

> We're using the same sanitizer that HTML format uses to produce a fragment
> with styles inlined. This is also the same sanitization process used in
> paste operation(ctrl+V).
>

OK, so that's the one specified in
https://github.com/w3c/clipboard-apis/issues/150?

--
> *From:* Yoav Weiss (@Shopify) 
> *Sent:* Tuesday, February 27, 2024 1:30 PM
> *To:* Anupam Snigdha 
> *Cc:* Daniel Bratell ; Chris Harrelson <
> chris...@chromium.org>; Thomas Steiner ; Evan Stade <
> est...@chromium.org>; Anupam Snigdha ; 一丝 <
> yio...@gmail.com>; blink-dev ;
> sligh...@chromium.org ; svo...@gmail.com <
> s...@voisen.org>; pwn...@chromium.org ; Marijn
> Kruisselbrink ; huang...@chromium.org <
> huangdar...@chromium.org>; mk...@chromium.org ;
> Joshua Bell ; christin...@chromium.org <
> christin...@chromium.org>; etiennen...@chromium.org <
> etiennen...@chromium.org>; Sanket Joshi (EDGE) 
> *Subject:* Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: Clipboard API:
> Svg
>
>
>
> On Tue, Feb 27, 2024 at 10:18 PM Anupam Snigdha 
> wrote:
>
>  I noticed that the tests here are marked as "tentative". Is the
> sanitizer part of this specified?
>
> Since there is no consensus on the clipboard sanitization, the tests are
> marked as tentative for now. We had discussions
> 
> in the past to
> standardize the sanitization process (in the context of HTML), but were not
> able to get consensus
> 
>
>
> Oh my..
>
> While consensus does seem elusive in this case, do you think it'd be
> possible to specify what we're shipping here, even if we can't standardize
> it right away?
>
> from other browser vendors.
>
>
> With the new Sanitizer API
> , hopefully we can
> standardize the sanitization process and make it consistent for all formats
> in the clipboard.
>
> --
> *From:* Yoav Weiss (@Shopify) 
> *Sent:* Tuesday, February 27, 2024 1:06 PM
> *To:* Daniel Bratell 
> *Cc:* Chris Harrelson ; Anupam Snigdha <
> sni...@microsoft.com>; Thomas Steiner ; Evan Stade <
> est...@chromium.org>; Anupam Snigdha ; 一丝 <
> yio...@gmail.com>; blink-dev ;
> sligh...@chromium.org ; svo...@gmail.com <
> s...@voisen.org>; pwn...@chromium.org ; Marijn
> Kruisselbrink ; huang...@chromium.org <
> huangdar...@chromium.org>; mk...@chromium.org ;
> Joshua Bell ; christin...@chromium.org <
> christin...@chromium.org>; etiennen...@chromium.org <
> etiennen...@chromium.org>; Sanket Joshi (EDGE) 
> *Subject:* Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: Clipboard API:
> Svg
>
>
> On Fri, Feb 23, 2024 at 7:40 PM Daniel Bratell 
> wrote:
>
> LGTM
>
> Not sure if it's LGTM2 or LGTM4 since that depends on if the 2021 LGTMS
> still apply, but this still seems ready to ship.
>
> /Daniel
> On 2024-02-23 19:14, Chris Harrelson wrote:
>
> My LGTM still stands, and have recorded it in the tool.
>
> On Fri, Feb 23, 2024 at 10:01 AM 'Anupam Snigdha' via blink-dev <
> blink-dev@chromium.org> wrote:
>
> Gentle ping.. Received signoffs for all review gates for this feature.
> --
> *From:* Anupam Snigdha 
> *Sent:* Monday, February 12, 2024 10:37 AM
> *To:* Thomas Steiner ; Chris Harrelson <
> chris...@chromium.org>
> *Cc:* Evan Stade ; Anupam Snigdha <
> snianu.micros...@gmail.com>; 一丝 ; blink-dev <
> blink-dev@chromium.org>; sligh...@chromium.org ;
> svo...@gmail.com ; pwn...@chromium.org <
> pwn...@chromium.org>; Marijn Kruisselbrink ;
> yoav...@chromium.org ; huang...@chromium.org <
> huangdar...@chromium.org>; mk...@chromium.org ;
> Joshua Bell ; christin...@chromium.org <
> christin...@chromium.org>; etiennen...@chromium.org <
> etiennen...@chromium.org>; Sanket Joshi (EDGE) 
> *Subject:* Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: Clipboard API:
> Svg
>
> I've made some changes
> 
> to
> address the loss of styles and other formatting issues during write. During
> read, if the authors have added `image/svg+xml` to the `unsanitized` list,
> then the SVG image content is returned without any strict processing by the
> browser. By-default, read processes the `image/svg+xml`using the strict
> HTML fragment parser that inlines the styles and strips out certain tags
> that may be security sensitive.
>
> I noticed that the tests here are marked as "tentative". Is the sanitizer
> part of this specified?
>
> I have started the privacy/security reviews for this change. Thanks!
>
> -Anupam
> --
> *From:* Thomas Steiner 
> *Sent:* Friday, February 2, 2024 12:45 AM
> *To:* Chris Harrelson 
> *Cc:* Evan Stade ; Anupam Snigdha <
> snianu.micros...@gmail.com>; 一丝 ; blink

Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: Clipboard API: Svg

['Anupam Snigdha' via blink-dev]

We're using the same sanitizer that HTML format uses to produce a fragment with 
styles inlined. This is also the same sanitization process used in paste 
operation(ctrl+V).

From: Yoav Weiss (@Shopify) 
Sent: Tuesday, February 27, 2024 1:30 PM
To: Anupam Snigdha 
Cc: Daniel Bratell ; Chris Harrelson 
; Thomas Steiner ; Evan Stade 
; Anupam Snigdha ; 一丝 
; blink-dev ; sligh...@chromium.org 
; svo...@gmail.com ; 
pwn...@chromium.org ; Marijn Kruisselbrink 
; huang...@chromium.org ; 
mk...@chromium.org ; Joshua Bell ; 
christin...@chromium.org ; etiennen...@chromium.org 
; Sanket Joshi (EDGE) 
Subject: Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: Clipboard API: Svg



On Tue, Feb 27, 2024 at 10:18 PM Anupam Snigdha 
mailto:sni...@microsoft.com>> wrote:
 I noticed that the tests here are marked as "tentative". Is the sanitizer part 
of this specified?
Since there is no consensus on the clipboard sanitization, the tests are marked 
as tentative for now. We had 
discussions 
 in the past to standardize 
the sanitization process (in the context of HTML), but were not able to get 
consensus

Oh my..

While consensus does seem elusive in this case, do you think it'd be possible 
to specify what we're shipping here, even if we can't standardize it right away?

from other browser vendors.

With the new Sanitizer 
API, hopefully we can 
standardize the sanitization process and make it consistent for all formats in 
the clipboard.


From: Yoav Weiss (@Shopify) 
mailto:yoavwe...@chromium.org>>
Sent: Tuesday, February 27, 2024 1:06 PM
To: Daniel Bratell mailto:bratel...@gmail.com>>
Cc: Chris Harrelson mailto:chris...@chromium.org>>; 
Anupam Snigdha mailto:sni...@microsoft.com>>; Thomas 
Steiner mailto:to...@google.com>>; Evan Stade 
mailto:est...@chromium.org>>; Anupam Snigdha 
mailto:snianu.micros...@gmail.com>>; 一丝 
mailto:yio...@gmail.com>>; blink-dev 
mailto:blink-dev@chromium.org>>; 
sligh...@chromium.org 
mailto:slightly...@chromium.org>>; 
svo...@gmail.com 
mailto:s...@voisen.org>>; 
pwn...@chromium.org 
mailto:pwn...@chromium.org>>; Marijn Kruisselbrink 
mailto:m...@chromium.org>>; 
huang...@chromium.org 
mailto:huangdar...@chromium.org>>; 
mk...@chromium.org 
mailto:mk...@chromium.org>>; Joshua Bell 
mailto:jsb...@chromium.org>>; 
christin...@chromium.org 
mailto:christin...@chromium.org>>; 
etiennen...@chromium.org 
mailto:etiennen...@chromium.org>>; Sanket Joshi 
(EDGE) mailto:sa...@microsoft.com>>
Subject: Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: Clipboard API: Svg


On Fri, Feb 23, 2024 at 7:40 PM Daniel Bratell 
mailto:bratel...@gmail.com>> wrote:

LGTM

Not sure if it's LGTM2 or LGTM4 since that depends on if the 2021 LGTMS still 
apply, but this still seems ready to ship.

/Daniel

On 2024-02-23 19:14, Chris Harrelson wrote:
My LGTM still stands, and have recorded it in the tool.

On Fri, Feb 23, 2024 at 10:01 AM 'Anupam Snigdha' via blink-dev 
mailto:blink-dev@chromium.org>> wrote:
Gentle ping.. Received signoffs for all review gates for this feature.

From: Anupam Snigdha mailto:sni...@microsoft.com>>
Sent: Monday, February 12, 2024 10:37 AM
To: Thomas Steiner mailto:to...@google.com>>; Chris Harrelson 
mailto:chris...@chromium.org>>
Cc: Evan Stade mailto:est...@chromium.org>>; Anupam 
Snigdha mailto:snianu.micros...@gmail.com>>; 一丝 
mailto:yio...@gmail.com>>; blink-dev 
mailto:blink-dev@chromium.org>>; 
sligh...@chromium.org 
mailto:slightly...@chromium.org>>; 
svo...@gmail.com 
mailto:s...@voisen.org>>; 
pwn...@chromium.org 
mailto:pwn...@chromium.org>>; Marijn Kruisselbrink 
mailto:m...@chromium.org>>; 
yoav...@chromium.org 
mailto:yoavwe...@chromium.org>>; 
huang...@chromium.org 
mailto:huangdar...@chromium.org>>; 
mk...@chromium.org 
mailto:mk...@chromium.org>>; Joshua Bell 
mailto:jsb...@chromium.org>>; 
christin...@chromium.org 
mailto:christin...@chromium.org>>; 
etiennen...@chromium.org 
mailto:etiennen...@chromium.org>>; Sanket Joshi 
(EDGE) mailto:sa...@microsoft.com>>
Subject: Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: Clipboard API: Svg

I've made some 
changes 
 to address 
the loss of styles and 

[blink-dev] Re: Web-Facing Change PSA: Interoperable mousedown event cancellation in iframe

[Tai Huynh]

Hi all! Thanks for posting this discussion. 

My name is Tai, and I'm an engineer at Webflow. Just wanted to comment that 
this change triggered a regression in our Designer editor. 

Our application architecture involves rendering the design editor within an 
iframe and surrounding it with tools in the main document, some of which 
overlay the iframe to facilitate direct on-canvas manipulation. A feature 
affected by this update is our Grid overlay tool, which allows users to 
drag and drop elements into different grid cells directly on the canvas. 

Previously, our users could start a mousedown event within the iframe (e.g. 
selecting an element to move) and drag it to an overlay in the main 
document (e.g. our Grid overlay), where the mouseenter event on the overlay 
would fire, allowing them to drop the element into a new grid cell.  After 
the update, the mouseenter event on the overlay no longer fires when the 
mouse event starts within the Iframe. This prevents the grid overlay 
feature from recognizing elements being dragged into it, which breaks the 
drag-and-drop experience. Users can no longer effectively place elements 
into specific cells of the grid, limiting the usability of our design tool.

I've attached a simple html file that outlines this issue that you can test 
on version 121 vs the latest

We're not sure how to handle this issue in this case, and I'm sure we're 
not the only apps that have a similar architecture and workflow. Can you 
help guide us towards a solution to address this spec-compliant change?

Thank you,
Tai

On Tuesday, January 9, 2024 at 12:40:32 PM UTC-8 Mustaq Ahmed wrote:

> Contact emailsmus...@chromium.org, fla...@chromium.org
>
> SpecificationNone
>
> Summary
>
> Make mouse event targets agnostic to mousedown event cancellation when the 
> pointer is dragged out of an iframe. When the mouse is dragged out of an 
> iframe, all browsers (including Chrome) send mousemove and mouseup events 
> to the iframe. However, if the mousedown event is cancelled, Chrome today 
> maintains an old WebKit exception that mousemove and mouseup events are 
> sent to the outer frame. WebKit removed this exception last year, and 
> Mozilla never showed this behavior in recent years. This feature will 
> remove the Chrome-only exception for this special case.
>
>
> Blink componentBlink>Input 
> 
>
> TAG reviewNone
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> This change will make Chrome fully interoperable with Firefox and Safari. 
> We don't expect many compat problems from this change as this is a desktop 
> focused special case in which Chrome is different from other browsers. I.e. 
> we would expect users to see the issues in other browsers already. The 
> compat risk is non-zero, however it is difficult to measure whether the 
> change to the frame target changes would be breaking without exposing the 
> change.
>
>
> *Gecko*: Shipped/Shipping
>
> *WebKit*: Shipped/Shipping (https://bugs.webkit.org/show_bug.cgi?id=262691
> )
>
> *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
>
>
> https://wpt.fyi/results/uievents/mouse/cancel-mousedown-in-subframe.html?label=experimental&label=master&aligned
>
>
> Flag name on chrome://flagsNone
>
> Finch feature nameMouseDragFromIframeOnCancelledMouseDown
>
> Requires code in //chrome?False
>
> Tracking bughttps://crbug.com/269917
>
> Sample links
>
> https://mustaqahmed.github.io/web/interop/cancel-mousedown-in-iframe-top.html
> https://codepen.io/mustaqahmed/full/yLjBraJ
>
> Estimated milestones
> Shipping on desktop 122
> Shipping on Android 122
> Shipping on WebView 122
>
> Anticipated spec changes
>
> Open questions about a feature may be a source of future web compat or 
> interop issues. Please list open issues (e.g. links to known github issues 
> in the project for the feature specification) whose resolution may 
> introduce web compat/interop risk (e.g., changing to naming or structure of 
> the API in a non-backward-compatible way).
> None
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5083240891416576
>
> 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 bl

Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: Clipboard API: Svg

[Yoav Weiss (@Shopify)]

On Tue, Feb 27, 2024 at 10:18 PM Anupam Snigdha 
wrote:

>  I noticed that the tests here are marked as "tentative". Is the
> sanitizer part of this specified?
>
> Since there is no consensus on the clipboard sanitization, the tests are
> marked as tentative for now. We had discussions
> 
> in the past to
> standardize the sanitization process (in the context of HTML), but were not
> able to get consensus
> 
>

Oh my..

While consensus does seem elusive in this case, do you think it'd be
possible to specify what we're shipping here, even if we can't standardize
it right away?

from other browser vendors.
>

> With the new Sanitizer API
> , hopefully we can
> standardize the sanitization process and make it consistent for all formats
> in the clipboard.
>
> --
> *From:* Yoav Weiss (@Shopify) 
> *Sent:* Tuesday, February 27, 2024 1:06 PM
> *To:* Daniel Bratell 
> *Cc:* Chris Harrelson ; Anupam Snigdha <
> sni...@microsoft.com>; Thomas Steiner ; Evan Stade <
> est...@chromium.org>; Anupam Snigdha ; 一丝 <
> yio...@gmail.com>; blink-dev ;
> sligh...@chromium.org ; svo...@gmail.com <
> s...@voisen.org>; pwn...@chromium.org ; Marijn
> Kruisselbrink ; huang...@chromium.org <
> huangdar...@chromium.org>; mk...@chromium.org ;
> Joshua Bell ; christin...@chromium.org <
> christin...@chromium.org>; etiennen...@chromium.org <
> etiennen...@chromium.org>; Sanket Joshi (EDGE) 
> *Subject:* Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: Clipboard API:
> Svg
>
>
> On Fri, Feb 23, 2024 at 7:40 PM Daniel Bratell 
> wrote:
>
> LGTM
>
> Not sure if it's LGTM2 or LGTM4 since that depends on if the 2021 LGTMS
> still apply, but this still seems ready to ship.
>
> /Daniel
> On 2024-02-23 19:14, Chris Harrelson wrote:
>
> My LGTM still stands, and have recorded it in the tool.
>
> On Fri, Feb 23, 2024 at 10:01 AM 'Anupam Snigdha' via blink-dev <
> blink-dev@chromium.org> wrote:
>
> Gentle ping.. Received signoffs for all review gates for this feature.
> --
> *From:* Anupam Snigdha 
> *Sent:* Monday, February 12, 2024 10:37 AM
> *To:* Thomas Steiner ; Chris Harrelson <
> chris...@chromium.org>
> *Cc:* Evan Stade ; Anupam Snigdha <
> snianu.micros...@gmail.com>; 一丝 ; blink-dev <
> blink-dev@chromium.org>; sligh...@chromium.org ;
> svo...@gmail.com ; pwn...@chromium.org <
> pwn...@chromium.org>; Marijn Kruisselbrink ;
> yoav...@chromium.org ; huang...@chromium.org <
> huangdar...@chromium.org>; mk...@chromium.org ;
> Joshua Bell ; christin...@chromium.org <
> christin...@chromium.org>; etiennen...@chromium.org <
> etiennen...@chromium.org>; Sanket Joshi (EDGE) 
> *Subject:* Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: Clipboard API:
> Svg
>
> I've made some changes
> 
> to
> address the loss of styles and other formatting issues during write. During
> read, if the authors have added `image/svg+xml` to the `unsanitized` list,
> then the SVG image content is returned without any strict processing by the
> browser. By-default, read processes the `image/svg+xml`using the strict
> HTML fragment parser that inlines the styles and strips out certain tags
> that may be security sensitive.
>
> I noticed that the tests here are marked as "tentative". Is the sanitizer
> part of this specified?
>
> I have started the privacy/security reviews for this change. Thanks!
>
> -Anupam
> --
> *From:* Thomas Steiner 
> *Sent:* Friday, February 2, 2024 12:45 AM
> *To:* Chris Harrelson 
> *Cc:* Evan Stade ; Anupam Snigdha <
> snianu.micros...@gmail.com>; 一丝 ; blink-dev <
> blink-dev@chromium.org>; sligh...@chromium.org ;
> svo...@gmail.com ; pwn...@chromium.org <
> pwn...@chromium.org>; Marijn Kruisselbrink ;
> yoav...@chromium.org ; huang...@chromium.org <
> huangdar...@chromium.org>; mk...@chromium.org ;
> Joshua Bell ; Anupam Snigdha ;
> christin...@chromium.org ;
> etiennen...@chromium.org 
> *Subject:* [EXTERNAL] Re: [blink-dev] Intent to Ship: Clipboard API: Svg
>
> Regarding developer interest, there's definitely some false positives in
> there, but a quick GitHub search
> 
>  demonstrates
> that quite a few developers attempt to write `image/svg+xml` onto the
> clipboard. (Including my own app, SVGcode
> 
> ).
>
> On Thu, Feb 1, 2024 at 11:45 PM Chris Harrelson 
> wrote:
>
>
>
> On Thu, Feb 1, 2024 at 2:43 PM Evan Stade  wrote:
>
> My understanding is that SVG support got lost in a pers

Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: Clipboard API: Svg

['Anupam Snigdha' via blink-dev]

 I noticed that the tests here are marked as "tentative". Is the sanitizer part 
of this specified?
Since there is no consensus on the clipboard sanitization, the tests are marked 
as tentative for now. We had 
discussions 
 in the past to standardize 
the sanitization process (in the context of HTML), but were not able to get 
consensus
 from other browser vendors.

With the new Sanitizer 
API, hopefully we can 
standardize the sanitization process and make it consistent for all formats in 
the clipboard.


From: Yoav Weiss (@Shopify) 
Sent: Tuesday, February 27, 2024 1:06 PM
To: Daniel Bratell 
Cc: Chris Harrelson ; Anupam Snigdha 
; Thomas Steiner ; Evan Stade 
; Anupam Snigdha ; 一丝 
; blink-dev ; sligh...@chromium.org 
; svo...@gmail.com ; 
pwn...@chromium.org ; Marijn Kruisselbrink 
; huang...@chromium.org ; 
mk...@chromium.org ; Joshua Bell ; 
christin...@chromium.org ; etiennen...@chromium.org 
; Sanket Joshi (EDGE) 
Subject: Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: Clipboard API: Svg


On Fri, Feb 23, 2024 at 7:40 PM Daniel Bratell 
mailto:bratel...@gmail.com>> wrote:

LGTM

Not sure if it's LGTM2 or LGTM4 since that depends on if the 2021 LGTMS still 
apply, but this still seems ready to ship.

/Daniel

On 2024-02-23 19:14, Chris Harrelson wrote:
My LGTM still stands, and have recorded it in the tool.

On Fri, Feb 23, 2024 at 10:01 AM 'Anupam Snigdha' via blink-dev 
mailto:blink-dev@chromium.org>> wrote:
Gentle ping.. Received signoffs for all review gates for this feature.

From: Anupam Snigdha mailto:sni...@microsoft.com>>
Sent: Monday, February 12, 2024 10:37 AM
To: Thomas Steiner mailto:to...@google.com>>; Chris Harrelson 
mailto:chris...@chromium.org>>
Cc: Evan Stade mailto:est...@chromium.org>>; Anupam 
Snigdha mailto:snianu.micros...@gmail.com>>; 一丝 
mailto:yio...@gmail.com>>; blink-dev 
mailto:blink-dev@chromium.org>>; 
sligh...@chromium.org 
mailto:slightly...@chromium.org>>; 
svo...@gmail.com 
mailto:s...@voisen.org>>; 
pwn...@chromium.org 
mailto:pwn...@chromium.org>>; Marijn Kruisselbrink 
mailto:m...@chromium.org>>; 
yoav...@chromium.org 
mailto:yoavwe...@chromium.org>>; 
huang...@chromium.org 
mailto:huangdar...@chromium.org>>; 
mk...@chromium.org 
mailto:mk...@chromium.org>>; Joshua Bell 
mailto:jsb...@chromium.org>>; 
christin...@chromium.org 
mailto:christin...@chromium.org>>; 
etiennen...@chromium.org 
mailto:etiennen...@chromium.org>>; Sanket Joshi 
(EDGE) mailto:sa...@microsoft.com>>
Subject: Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: Clipboard API: Svg

I've made some 
changes 
 to address 
the loss of styles and other formatting issues during write. During read, if 
the authors have added `image/svg+xml` to the `unsanitized` list, then the SVG 
image content is returned without any strict processing by the browser. 
By-default, read processes the `image/svg+xml`using the strict HTML fragment 
parser that inlines the styles and strips out certain tags that may be security 
sensitive.
I noticed that the tests here are marked as "tentative". Is the sanitizer part 
of this specified?
I have started the privacy/security reviews for this change. Thanks!

-Anupam

From: Thomas Steiner mailto:to...@google.com>>
Sent: Friday, February 2, 2024 12:45 AM
To: Chris Harrelson mailto:chris...@chromium.org>>
Cc: Evan Stade mailto:est...@chromium.org>>; Anupam 
Snigdha mailto:snianu.micros...@gmail.com>>; 一丝 
mailto:yio...@gmail.com>>; blink-dev 
mailto:blink-dev@chromium.org>>; 
sligh...@chromium.org 
mailto:slightly...@chromium.org>>; 
svo...@gmail.com 
mailto:s...@voisen.org>>; 
pwn...@chromium.org 
mailto:pwn...@chromium.org>>; Marijn Kruisselbrink 
mailto:m...@chromium.org>>; 
yoav...@chromium.org 
mailto:yoavwe...@chromium.org>>; 
huang...@chromium.org 
mailto:huangdar...@chromium.org>>; 
mk...@chromium.org 
mailto:mk...@chromium.org>>; Joshua Bell 
mailto:jsb...@chromium.org>>; Anupam Snigdha 
mailto:sni...@microsoft.com>>; 
christin...@chromium.org 
mailto:christin...@chromium.org>>; 
etiennen...@chromium.org 
mailto:etiennen...@chromium.org>>
Subject: [EXTERNAL] Re:

Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: Clipboard API: Svg

[Yoav Weiss (@Shopify)]

On Fri, Feb 23, 2024 at 7:40 PM Daniel Bratell  wrote:

> LGTM
>
> Not sure if it's LGTM2 or LGTM4 since that depends on if the 2021 LGTMS
> still apply, but this still seems ready to ship.
>
> /Daniel
> On 2024-02-23 19:14, Chris Harrelson wrote:
>
> My LGTM still stands, and have recorded it in the tool.
>
> On Fri, Feb 23, 2024 at 10:01 AM 'Anupam Snigdha' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Gentle ping.. Received signoffs for all review gates for this feature.
>> --
>> *From:* Anupam Snigdha 
>> *Sent:* Monday, February 12, 2024 10:37 AM
>> *To:* Thomas Steiner ; Chris Harrelson <
>> chris...@chromium.org>
>> *Cc:* Evan Stade ; Anupam Snigdha <
>> snianu.micros...@gmail.com>; 一丝 ; blink-dev <
>> blink-dev@chromium.org>; sligh...@chromium.org ;
>> svo...@gmail.com ; pwn...@chromium.org <
>> pwn...@chromium.org>; Marijn Kruisselbrink ;
>> yoav...@chromium.org ; huang...@chromium.org <
>> huangdar...@chromium.org>; mk...@chromium.org ;
>> Joshua Bell ; christin...@chromium.org <
>> christin...@chromium.org>; etiennen...@chromium.org <
>> etiennen...@chromium.org>; Sanket Joshi (EDGE) 
>> *Subject:* Re: [EXTERNAL] Re: [blink-dev] Intent to Ship: Clipboard API:
>> Svg
>>
>> I've made some changes
>> 
>> to
>> address the loss of styles and other formatting issues during write. During
>> read, if the authors have added `image/svg+xml` to the `unsanitized` list,
>> then the SVG image content is returned without any strict processing by the
>> browser. By-default, read processes the `image/svg+xml`using the strict
>> HTML fragment parser that inlines the styles and strips out certain tags
>> that may be security sensitive.
>>
> I noticed that the tests here are marked as "tentative". Is the sanitizer
part of this specified?

> I have started the privacy/security reviews for this change. Thanks!
>>
>> -Anupam
>> --
>> *From:* Thomas Steiner 
>> *Sent:* Friday, February 2, 2024 12:45 AM
>> *To:* Chris Harrelson 
>> *Cc:* Evan Stade ; Anupam Snigdha <
>> snianu.micros...@gmail.com>; 一丝 ; blink-dev <
>> blink-dev@chromium.org>; sligh...@chromium.org ;
>> svo...@gmail.com ; pwn...@chromium.org <
>> pwn...@chromium.org>; Marijn Kruisselbrink ;
>> yoav...@chromium.org ; huang...@chromium.org <
>> huangdar...@chromium.org>; mk...@chromium.org ;
>> Joshua Bell ; Anupam Snigdha ;
>> christin...@chromium.org ;
>> etiennen...@chromium.org 
>> *Subject:* [EXTERNAL] Re: [blink-dev] Intent to Ship: Clipboard API: Svg
>>
>> Regarding developer interest, there's definitely some false positives in
>> there, but a quick GitHub search
>> 
>>  demonstrates
>> that quite a few developers attempt to write `image/svg+xml` onto the
>> clipboard. (Including my own app, SVGcode
>> 
>> ).
>>
>> On Thu, Feb 1, 2024 at 11:45 PM Chris Harrelson 
>> wrote:
>>
>>
>>
>> On Thu, Feb 1, 2024 at 2:43 PM Evan Stade  wrote:
>>
>> My understanding is that SVG support got lost in a personnel shuffle and
>> that we would like to ship it in theory. This comment
>>  has
>> some more context, the takeaways being that:
>>
>>- we need to be more sure of the implementation
>>- we need partner confirmation, i.e. addressing "LGTM3 with the
>>caveat that we should only flip this flag to ship if big customers like
>>Sean's team are able to use this successfully to minimally cover their
>>needs."
>>
>> From my perspective the LGTMs are no longer caveated. I think there is
>> enough evidence of demand to just do it.
>>
>>
>> No one has done that outreach as of yet.
>>
>> -- Evan Stade
>>
>>
>> On Thu, Feb 1, 2024 at 2:35 PM Chris Harrelson 
>> wrote:
>>
>> Hi,
>>
>> From my perspective, you still have 3 LGTMs to ship from the API owners.
>> However, please fill out the cross-functional reviews for privacy,
>> security, etc that have been added to the process since this intent was
>> created. If that doesn't seem possible with your existing chromestatus
>> entry, let me know or just create a new one and I'll LGTM it after those
>> reviews have started.
>>
>> On Thu, Feb 1, 2024 at 1:38 PM Anupam Snigdha 
>> wrote:
>>
>> Thanks Chris!
>> cc'ing estade@.
>> I think Darwin and Victor are not working on clipboard anymore so this
>> feature was stalled.
>>
>> Recently another bug was opened (
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1410321) where
>> support for copying/pasting svg images is needed. More discussions:
>> https://boxy-svg.com/ideas/268/paste-images-from-the-system-clipboard#comment-2313
>> Since this I2S was LGTM'd with the

Re: [blink-dev] Intent to Prototype and Ship: Standardized CSS zoom

[Yoav Weiss (@Shopify)]

On Mon, Feb 26, 2024 at 7:36 PM Mike Taylor  wrote:

> Thanks for the feedback Noam - would you mind filing a bug at
> crbug.com/new that contains some steps to reproduce the breakage, and
> possibly some affected codepaths and report back here? Agree that breaking
> Excel is not a great outcome.
>
That's an understatement..

> On 2/26/24 10:01 AM, Noam Helfman wrote:
>
> Great to see work is being done to get this standardized!
>
> However, I think it should not be shipped yet.
>
> We have done some basic testing of this feature with Excel Online and it
> breaks lots of critical user scenarios related to our zoom feature. This
> will impact many millions of users and regress a major feature.
>
> We will need to spend time to investigate if there is a simple workaround
> that we can use to address this regression.
>
> Few questions:
> 1. What is the expected timeline to ship this?
>
> Good question. +Yotam Hacohen  may be able to say
more. For now, I see that the feature is still not enabled by default

.

> 2. Is there an option to programatically determine if the feature is
> enabled? (e.g. would *CSS.supports("zoom")* return *true*? )
> 3. Will there be an option to enable/disable it (e.g. release with OT)?
>
> It might be a good idea to have an OT that turns this feature off, even if
it's only for Excel. (although if we missed this breakage, I wonder what
other breakage we may have missed)

>
> Please do not ship this until we can confirm we have a workaround or the
> API is adapted in a way that does not regress existing behavior.
>
> Thanks,
> Noam
> On Thursday, February 15, 2024 at 12:18:06 PM UTC+2 Daniel Bratell wrote:
>
>> Same for me. A proprietary long term CSS property is now fully
>> standardized and will be interoperable. This is a win for the web, and
>> thank you for all who worked to make it happen!
>>
>> /Daniel
>> On 2024-02-14 18:13, Yoav Weiss (@Shopify) wrote:
>>
>> Just wanted to say that it's exciting to see this standardized after all
>> these years. Given the manual inspection, it seems like shipping this to
>> 100% with a killswitch is (hopefully) safe enough!
>>
>> On Wed, Feb 14, 2024 at 6:11 PM Yoav Weiss (@Shopify) <
>> yoav...@chromium.org> wrote:
>>
>>> LGTM3
>>>
>>> On Wed, Feb 14, 2024 at 6:00 PM Philip Jägenstedt 
>>> wrote:
>>>
 LGTM2

 On Wed, Feb 14, 2024 at 11:53 PM Daniel Bratell 
 wrote:
 >
 > LGTM1
 >
 > /Daniel
 >
 > On 2024-02-09 20:24, 'Yotam Hacohen' via blink-dev wrote:
 >
 >
 >
 > On Thursday, February 8, 2024 at 6:46:00 PM UTC-8 Domenic Denicola
 wrote:
 >
 > On Fri, Feb 9, 2024 at 10:55 AM Yotam Hacohen 
 wrote:
 >
 > Hey Dominic and thanks for the input!
 >
 > On Sunday, February 4, 2024 at 7:34:53 PM UTC-8 Domenic Denicola
 wrote:
 >
 > It's always exciting to move such an old feature from nonstandard to
 standardized!
 >
 > On Sat, Feb 3, 2024 at 4:18 AM 'Yotam Hacohen' via blink-dev <
 blin...@chromium.org> wrote:
 >
 > Contact emailsyo...@google.com
 >
 > ExplainerNone
 >
 >
 > FWIW, I think the contents of
 https://github.com/w3c/csswg-drafts/pull/9699 and
 https://drafts.csswg.org/css-viewport/#zoom-property are probably a
 good enough explainer. It might be a good idea to update ChromeStatus to
 link to them.
 >
 > Added those. Thanks!
 >
 >
 >
 >
 >
 > Specificationhttps://github.com/w3c/csswg-drafts/pull/9699
 >
 > Design docshttps://
 docs.google.com/document/d/1AcnDShjT-kEuRaMchZPm5uaIgNZ4OiYtM4JI9qiV8Po/edit
 >
 > Summary
 >
 > Aligns the existing implementation of the previously non-standard CSS
 zoom property to align with the new standard. This changes various JS APIs
 to align with the spec (see design doc), change zoom to apply to iframes,
 and change it to apply to all inherit all length properties (currently it
 only changes inherited font-size)
 >
 >
 > Blink componentBlink>Paint
 >
 > TAG reviewNone
 >
 > TAG review statusPending
 >
 >
 > Probably this fits under the first exception here.
 >
 >
 >
 >
 > Risks
 >
 > Interoperability and Compatibility
 >
 > There is web compatibility risk for these changes. However, previous
 research indicates broken content due to unexpected changes of the JS APIs
 is very unlikely, since: * The changes to the JS API simply change the
 coordinate space of the responses, not the syntax or what APIs are
 available. * Most pages found during the research didn't appear to use CSS
 zoom at all and the ones that did only relied on the visual effect, not JS
 APIs. It's possible some pages will be brok

Re: [blink-dev] Intent to Experiment: FedCM multi IDP in single get() call

[Yoav Weiss (@Shopify)]

LGTM to experiment M124-M128 inclusive

On Tue, Feb 27, 2024 at 4:16 PM Nicolás Peña  wrote:

> Done
>
> On Monday, February 26, 2024 at 7:55:09 PM UTC-5 Mike Taylor wrote:
>
>> Could you please request reviews for the privacy/security/debuggability
>> review gates in your chromestatus entry?
>> On 2/21/24 3:21 PM, Nicolás Peña wrote:
>>
>> Contact emails
>>
>> n...@chromium.org
>>
>> Explainer
>>
>> The Federated Credential Management (FedCM) API currently only allows one
>> identity provider (IDP) to be used when performing federated login in a
>> website. We would like to experiment with allowing multiple providers to be
>> specified in a single JavaScript get() call, which allows FedCM to be used
>> in cases for which the website supports multiple IDPs for federation. See
>> also additional context in https://github.com/fedidcg/FedCM/issues/319.
>>
>> Specification
>>
>> https://fedidcg.github.io/FedCM
>>
>> Summary
>>
>> Allows FedCM to show multiple IDPs in the same dialog. This provides
>> developers with a convenient way to present all supported identity
>> providers to users. In this I2E, we are tackling the simple case of having
>> all providers in the same get() call, while building much of the UX
>> infratructure that will allow us to tackle more sophisticated production
>> structures later.
>>
>>
>> Blink component
>>
>> Blink>Identity>FedCM
>> 
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/803
>>
>> TAG review status
>>
>> Pending
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> This should not have additional interop risks on top of the existing
>> FedCM API which is generally supported but not yet implemented by Firefox
>> and Safari. In order to determine whether multiple IDPs are supported in a
>> browser which supports FedCM, the developer can attempt to first call get()
>> with multiple IDPs. It will be rejected immediately if not supported and
>> the RP can retry with a single IDP.
>>
>>
>> Gecko: No signal (
>> https://github.com/mozilla/standards-positions/issues/730)
>>
>> WebKit: No signal (
>> https://github.com/WebKit/standards-positions/issues/120)
>>
>> Web developers: Positive (https://github.com/fedidcg/FedCM/issues/319)
>>
>> Other signals:
>>
>> Ergonomics
>>
>> Using this API will just require expanding the get() to use more
>> providers, so it will benefit from the ergonomics of the initial FedCM API.
>>
>>
>> Activation
>>
>> The main activation issue is having to include all IDPs in the same get()
>> call, which may be challenging in some cases because IDPs generally are
>> independent from each other. That said, we do have developers who can use
>> the single get() call, so we wish to start with the simpler version of
>> multi IDP support.
>>
>>
>> Security
>>
>> The security considerations are similar to those of the single IDP case.
>> We do not require users to input usernames and passwords due to spoofing
>> concerns, and we also have input protection to prevent accidental click
>> right after the UI is shown.
>>
>>
>> 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, FedCM is not supported on WebView
>>
>>
>> Goals for experimentation
>>
>> We want to ensure that the single get() call is sufficient for the use
>> cases we are targeting, where the multiple IDPs are owned by a single
>> entity, as well as gather developer feedback before fully shipping. The
>> multiple independent IDPs scenario is out of scope for experimentation, as
>> we anticipate that it will be hard to impossible to use FedCM in a single
>> get() call in such a scenario.
>>
>> A successful trial would result in our partner requesting us to ship this
>> feature to allow using FedCM with their multiple IDPs.
>>
>> Ongoing technical constraints
>>
>> None
>>
>>
>> Debuggability
>>
>> The debug tools are similar to that of original FedCM: console messages
>> and DevTools issues. Seeing FedCM network requests is not supported in
>> DevTools but can be achieved via chrome://net-export.
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, ChromeOS, Android, and Android WebView)?
>>
>> No
>>
>> As with the initial FedCM, we do not support Android WebView.
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>>
>> Yes
>>
>>
>> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/credential-management/fedcm-multi-idp/
>> Some of these tests are not relevant as they are related to the multi-get()
>> approach.
>>
>>
>> Flag name on chrome://flags
>>
>> FedCmMultiIdp
>>
>> Finch feature name
>>
>> FedCmMultipleIdentityProviders
>>
>> Requires code in //chrome?
>>
>

Re: [blink-dev] Intent to Ship: CSS paint-order for non-SVG text

[Stefan Zager]

I removed 'tentative' from the test name (PR
).

On Thu, Feb 15, 2024 at 6:15 PM Mike Taylor  wrote:

> LGTM3, with the same conditions from Chris.
> On 2/15/24 6:15 PM, Chris Harrelson wrote:
>
> LGTM2, conditioned on also making the tests Rego mentioned non-tentative.
>
> On Mon, Feb 12, 2024 at 11:05 AM Stefan Zager  wrote:
>
>> Done (requested N/A).
>>
>> On Mon, Feb 12, 2024 at 3:05 AM Manuel Rego Casasnovas 
>> wrote:
>>
>>> Oops, before we can approve you have to fill the other review gates at
>>> chromestatus, e.g.
>>> https://chromestatus.com/feature/5178467903864832?gate=5166816630669312
>>>
>>> Could you make sure you request the review for all the gates: Privacy,
>>> Security, Enterprise, Debuggability and Testing?
>>>
>>> Thanks!
>>>Rego
>>>
>>> On 12/02/2024 12:02, Manuel Rego Casasnovas wrote:
>>> > LGTM1.
>>> >
>>> > Good to know it's a different issue in Firefox.
>>> >
>>> > Now that all browsers will be supporting this, please could you make
>>> the
>>> > test non tentative?
>>> >
>>> > JFYI, I've filled an issue so the MDN documentation gets updated to
>>> also
>>> > include the HTML case: https://github.com/mdn/content/issues/32236
>>> >
>>> > Cheers,
>>> >Rego
>>> >
>>> > On 09/02/2024 09:00, Stefan Zager wrote:
>>> >>
>>> >>
>>> >> On Thu, Feb 8, 2024 at 4:00 AM Manuel Rego Casasnovas <
>>> r...@igalia.com
>>> >> > wrote:
>>> >>
>>> >> Why is the WPT test marked as tentative?
>>> >>
>>> >>
>>> https://wpt.fyi/results/css/css-fill-stroke/paint-order-001.tentative.html
>>> <
>>> https://wpt.fyi/results/css/css-fill-stroke/paint-order-001.tentative.html
>>> >
>>> >>
>>> >> Not sure if there are more tests or is only that one, but it's
>>> >> failing
>>> >> in Firefox. What are the interop issues? Are those reported
>>> >> somewhere?
>>> >>
>>> >>
>>> >> Looks like an implementation-specific line-breaking issue in the
>>> >> Firefox runs, but the text rendering appears consistent with webkit
>>> >> and chromium.
>>> >>
>>> >> I'm unaware of any interop issues.
>>> >>
>>> >>
>>> >> Thanks,
>>> >> Rego
>>> >>
>>> >> On 08/02/2024 11:48, Fredrik Söderquist wrote:
>>> >>  > On Thu, Feb 8, 2024 at 11:30 AM Daniel Bratell
>>> >> mailto:bratel...@gmail.com>
>>> >>  > >>
>>> wrote:
>>> >>  >
>>> >>  > __
>>> >>  >
>>> >>  > I didn't really get how it affects non-SVG text. The
>>> >> documentation
>>> >>  > and the examples are all for SVG. Is there HTML text that
>>> is
>>> >> also a
>>> >>  > mix of stroke, fill and marker blitting?
>>> >>  >
>>> >>  > Here's an example for non-SVG (HTML) text:
>>> >>  > https://jsfiddle.net/4mh71efb/ >> >
>>> >> >
>>> >>  >
>>> >>  > Getting a stroke on HTML text requires using the
>>> >> -webkit-text-stroke-*
>>> >>  > family of properties. Markers don't apply to text (same as for
>>> >> SVG text).
>>> >>  >
>>> >>  >
>>> >>  > /fs
>>> >>  >
>>> >>  > /Daniel
>>> >>  >
>>> >>  > On 2024-02-08 10:14, Fredrik Söderquist wrote:
>>> >>  >> On Thu, Feb 8, 2024 at 2:48 AM Stefan Zager
>>> >> mailto:sza...@chromium.org>
>>> >>  >> >> >>>
>>> >> wrote:
>>> >>  >>
>>> >>  >>
>>> >>  >> Contact emails
>>> >>  >>
>>> >>  >> sza...@chromium.org 
>>> >> >
>>> >>  >>
>>> >>  >>
>>> >>  >> Explainer
>>> >>  >>
>>> >>  >> https://developer.mozilla.org/en-US/docs/Web/CSS/paint-order
>>> >> 
>>> >>  >>
>>> >>  >> >> >
>>> >>  >>
>>> >>  >>
>>> >>  >> Specification
>>> >>  >>
>>> >>  >> https://svgwg.org/svg2-draft/painting.html#PaintOrder
>>> >> 
>>> >>  >> <
>>> https://svgwg.org/svg2-draft/painting.html#PaintOrder
>>> >> >
>>> >>  >>
>>> >>  >>
>>> >>  >> Summary
>>> >>  >>
>>> >>  >> Adds support for the existing CSS property
>>> >> `paint-order`. This
>>> >>  >> change only affects html (non-SVG) text; SVG text
>>> already
>>> >>  >> supports paint-order via attribute or CSS property.
>>> >>  >>
>>> >>  >>
>>> >>  >>
>>> >>  >> Blink component
>>> >>  >>
>>> >>  >> Blink

Re: [blink-dev] Intent to Experiment: FedCM multi IDP in single get() call

[Nicolás Peña]

Done

On Monday, February 26, 2024 at 7:55:09 PM UTC-5 Mike Taylor wrote:

> Could you please request reviews for the privacy/security/debuggability 
> review gates in your chromestatus entry?
> On 2/21/24 3:21 PM, Nicolás Peña wrote:
>
> Contact emails 
>
> n...@chromium.org
>
> Explainer 
>
> The Federated Credential Management (FedCM) API currently only allows one 
> identity provider (IDP) to be used when performing federated login in a 
> website. We would like to experiment with allowing multiple providers to be 
> specified in a single JavaScript get() call, which allows FedCM to be used 
> in cases for which the website supports multiple IDPs for federation. See 
> also additional context in https://github.com/fedidcg/FedCM/issues/319.
>
> Specification 
>
> https://fedidcg.github.io/FedCM
>
> Summary 
>
> Allows FedCM to show multiple IDPs in the same dialog. This provides 
> developers with a convenient way to present all supported identity 
> providers to users. In this I2E, we are tackling the simple case of having 
> all providers in the same get() call, while building much of the UX 
> infratructure that will allow us to tackle more sophisticated production 
> structures later.
>
>
> Blink component 
>
> Blink>Identity>FedCM 
> 
>
> TAG review 
>
> https://github.com/w3ctag/design-reviews/issues/803
>
> TAG review status 
>
> Pending
>
> Risks
>
> Interoperability and Compatibility 
>
> This should not have additional interop risks on top of the existing FedCM 
> API which is generally supported but not yet implemented by Firefox and 
> Safari. In order to determine whether multiple IDPs are supported in a 
> browser which supports FedCM, the developer can attempt to first call get() 
> with multiple IDPs. It will be rejected immediately if not supported and 
> the RP can retry with a single IDP.
>
>
> Gecko: No signal (
> https://github.com/mozilla/standards-positions/issues/730)
>
> WebKit: No signal (
> https://github.com/WebKit/standards-positions/issues/120)
>
> Web developers: Positive (https://github.com/fedidcg/FedCM/issues/319)
>
> Other signals:
>
> Ergonomics 
>
> Using this API will just require expanding the get() to use more 
> providers, so it will benefit from the ergonomics of the initial FedCM API.
>
>
> Activation 
>
> The main activation issue is having to include all IDPs in the same get() 
> call, which may be challenging in some cases because IDPs generally are 
> independent from each other. That said, we do have developers who can use 
> the single get() call, so we wish to start with the simpler version of 
> multi IDP support.
>
>
> Security 
>
> The security considerations are similar to those of the single IDP case. 
> We do not require users to input usernames and passwords due to spoofing 
> concerns, and we also have input protection to prevent accidental click 
> right after the UI is shown.
>
>
> 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, FedCM is not supported on WebView
>
>
> Goals for experimentation 
>
> We want to ensure that the single get() call is sufficient for the use 
> cases we are targeting, where the multiple IDPs are owned by a single 
> entity, as well as gather developer feedback before fully shipping. The 
> multiple independent IDPs scenario is out of scope for experimentation, as 
> we anticipate that it will be hard to impossible to use FedCM in a single 
> get() call in such a scenario.
>
> A successful trial would result in our partner requesting us to ship this 
> feature to allow using FedCM with their multiple IDPs.
>
> Ongoing technical constraints 
>
> None
>
>
> Debuggability 
>
> The debug tools are similar to that of original FedCM: console messages 
> and DevTools issues. Seeing FedCM network requests is not supported in 
> DevTools but can be achieved via chrome://net-export.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac, 
> Linux, ChromeOS, Android, and Android WebView)? 
>
> No
>
> As with the initial FedCM, we do not support Android WebView.
>
>
> Is this feature fully tested by web-platform-tests 
> 
> ? 
>
> Yes
>
>
> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/credential-management/fedcm-multi-idp/
>  
> Some of these tests are not relevant as they are related to the multi-get() 
> approach.
>
>
> Flag name on chrome://flags 
>
> FedCmMultiIdp
>
> Finch feature name 
>
> FedCmMultipleIdentityProviders
>
> Requires code in //chrome? 
>
> True
>
> Tracking bug 
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1348262
>
> Launch bug 
>
> https://launch.corp.google.com/launch/4229762
>
> Estimated milestones 
>
> DevT

Re: [blink-dev] Intent to Experiment: Add JavaScript timer wake up alignment for unimportant cross-origin frames

[Zheda Chen]

fdoray@ launched this trial since Nov 2023, at first canary/dev, and then 
beta, 1% stable. The experiments show statistically improvements to CPU 
time on navigation, page load time and input delay. 
So we are requesting to experiment on 50% stable as next step.

Actually the feature should be in origin trial stage now. But I don't have 
the permission to add origin trial stage. I have to use dev trial instead. 
Need some help from webstatus-request@ to grant me the permission.

On Tuesday, February 27, 2024 at 8:53:34 AM UTC+8 mike...@chromium.org 
wrote:

> Hello,
>
> To clarify: is this intended to be an I2E, or a Developer Trial? According 
> to https://chromestatus.com/feature/5106220399853568, it appears you are 
> in the dev trial stage. But you mention stable experiment below... so 
> perhaps that's a process mistake?
>
> Can you give more info on the experiment timelines and what stable 
> percentages you are requesting permission to experiment on?
>
> On 2/22/24 2:30 AM, Zheda Chen wrote:
>
> Contact emails 
> zheda...@intel.com, fdo...@chromium.org
>
> Specification
> https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html
>
> Summary 
>
> Align wake ups of JavaScript timers for unimportant cross-origin frames. 
> Currently, DOM timers <32ms are all opt-out from AlignWakeUps [1] due to 
> performance concerns. This is very conservative and actually some 
> unimportant frames are eligible to use JS timer alignment. WebKit uses the 
> policy to align DOM timer of non-interacted cross origin frames to 30ms. 
> This feature adds JavaScript timer wake up alignment for unimportant frames 
> on foreground pages. Unimportant frames means they are cross origin, 
> visible but have small proportion of page’s visible area, and have no user 
> interaction. [1] 
> https://chromium-review.googlesource.com/c/chromium/src/+/4589092
>
> Do you have plans to specify this concept of "unimportant frames" 
> somewhere?
>
>
>
> Blink component
> Blink>PerformanceAPIs>Timers 
> 
>
> TAG review
> None
>
> TAG review status
>
> Not applicable
>
> Risks 
>
>
> Interoperability and Compatibility 
>
> None
>
>
> *Gecko*: No signal
>
> *WebKit*: No signal
>
> *Web developers*: No signals
>
> *Other signals*:
>
> WebView application risks 
>
> Does this intent deprecate or change behavior of existing APIs, such that 
> it has potentially high risk for Android WebView-based applications?
>
> None
>
>
> Goals for experimentationWe plan to experiment on stable to confirm 
> whether we observe same performance improvement as on lower channels and 
> similar power benefit as in the lab. We will decide whether this feature 
> ships based on the experiment data.
>
>
>
> Ongoing technical constraints 
>
> 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 
> 
> ?
> No
>
> Flag name on chrome://flags
> None
>
> Finch feature name
> ThrottleUnimportantFrameTimers
>
> Requires code in //chrome?
> False
>
> Tracking bug
> https://issues.chromium.org/issues/40942028
>
> Estimated milestones
> DevTrial on desktop
> 122
> DevTrial on Android
> 122
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5106220399853568
>
> 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+...@chromium.org.
> To view this discussion on the web visit 
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/38855cfe-3bf3-4a04-b96a-81adaa5ba72fn%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/f7793487-9d55-458e-a06a-9860c3403826n%40chromium.org.