Re: [blink-dev] Intent to Deprecate and Remove: 0.0.0.0 for Private Network Access

['Vladimir Levin' via blink-dev]

LGTM3

On Wed, Jun 5, 2024 at 11:43 AM Yoav Weiss (@Shopify) <
yoavwe...@chromium.org> wrote:

> LGTM2
>
> On Wed, Jun 5, 2024 at 5:41 PM Daniel Bratell  wrote:
>
>> LGTM1
>>
>> /Daniel
>> On 2024-06-03 18:03, 'David Adrian' via blink-dev wrote:
>>
>> Contact emails l...@chromium.org
>>
>> Explainer None
>>
>> Specification https://wicg.github.io/private-network-access
>>
>> Summary
>>
>> We propose to block access to IP address 0.0.0.0 in advance of PNA
>> completely rolling out. Chrome is deprecating direct access to private
>> network endpoints from public websites as part of the Private Network
>> Access (PNA) specification (
>> https://developer.chrome.com/blog/private-network-access-preflight/).
>> Services listening on the localhost (127.0.0.0/8) are considered private
>> according to the specification (
>> https://wicg.github.io/private-network-access/#ip-address-space-heading).
>> Chrome's PNA protection (rolled out as part of
>> https://chromestatus.com/feature/5436853517811712) can be bypassed using
>> the IP address 0.0.0.0 to access services listening on the localhost on
>> macOS and Linux. This can also be abused in DNS rebinding attacks targeting
>> a web application listening on the localhost. Since 0.0.0.0 is not used in
>> practice (and should not be used), but was overlooked during
>> https://chromestatus.com/feature/5436853517811712, we're deprecating it
>> separately from the rest of the private network requests deprecation. This
>> will be a Finch (experimental) rollout, rather than a Developer Trial.
>>
>>
>> Blink component Blink>SecurityFeature>CORS>PrivateNetworkAccess
>> 
>>
>> Search tags security , 
>> Private
>> Network Access
>> 
>>
>> TAG review None
>>
>> TAG review status Not applicable
>>
>> Chromium Trial Name PrivateNetworkAccessNullIpAddressAllowed
>>
>> Origin Trial documentation link https://crbug.com/1300021
>>
>> WebFeature UseCounter name kPrivateNetworkAccessNullIpAddress
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> None
>>
>>
>> *Gecko*: Closed Without a Position (
>> https://github.com/mozilla/standards-positions/issues/143)
>>
>> *WebKit*: Support (
>> https://github.com/WebKit/standards-positions/issues/163)
>>
>> *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 experimentation
>>
>> Ongoing technical constraints
>>
>> Eventually, all private network access will be limited according to the
>> developing Private Network Access spec.
>>
>>
>> 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 block-null-ip-address
>>
>> Finch feature name PrivateNetworkAccessNullIpAddress
>>
>> Requires code in //chrome? False
>>
>> Tracking bug https://crbug.com/1300021
>>
>> Estimated milestones
>> Shipping on desktop 133
>> Origin trial desktop first 127
>> Origin trial desktop last 133
>> DevTrial on desktop 127
>> Shipping on Android 133
>> OriginTrial Android last 133
>> OriginTrial Android first 127
>> DevTrial on Android 127
>> Shipping on WebView 133
>> OriginTrial webView last 133
>> OriginTrial webView first 127
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5106143060033536
>>
>> 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/CAGkh42L-7xt9YY-jmq-G4-nuitqELpgqgnvECkbCoPpAWWMMjw%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/683cadae-9413-4125-9209-4ecfe1b812aa%40sarasas.se
>> 

Re: [blink-dev] Intent to Deprecate and Remove: Deprecate old CSS custom state syntax

['Vladimir Levin' via blink-dev]

Hey,

0.04% seems like a fairly sizable number. Do you know what the breakage
looks like or whether this usage is limited to a library/a small set of
large websites or something else?

Ideally, this is feature detected with some fallback syntax


On Tue, May 21, 2024 at 1:39 PM Joey Arhar  wrote:

> Contact emailsjar...@chromium.org
>
> ExplainerNone
>
> Specificationhttps://github.com/whatwg/html/pull/8467
>
> Summary
>
> The CSS custom state pseudo-class is being renamed from :--foo to
> :state(foo). The new syntax, :state(foo), has been enabled by default, and
> now we have to deprecate and remove the :--foo syntax. Gecko and webkit
> never implemented the old syntax and they have both shipped the new syntax.
> We are currently shipping both the new syntax and the old syntax at the
> same time. There have been console errors and DevTools deprecations for the
> old syntax for many milestones already. Previous thread on this topic:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/JvpHoUfhJYE/m/uRtWiqoHAQAJ
> The UseCounter is currently at 0.04%
> https://chromestatus.com/metrics/feature/timeline/popularity/3796
>
>
> Blink componentBlink>HTML>CustomElements
> 
>
> Motivation
>
> The syntax of this feature needs to change in order to get support from
> the other browsers and eventually have interoperable behavior.
>
>
> Initial public proposalNone
>
> TAG reviewNone
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> Websites which are currently using the old syntax and don't migrate to the
> new syntax will have CSS selectors which become invalid which would impact
> the styling of their custom elements.
>
>
> *Gecko*: Positive Firefox has shipped the new syntax
>
> *WebKit*: Positive (
> https://github.com/whatwg/html/pull/8467#issuecomment-1381645661) Safari
> has shipped the new syntax
>
> *Web developers*: No signals
>
> *Other signals*:
>
> Activation
>
> Switching to the new syntax is easy.
>
>
> 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/custom-elements/state
>
>
> Flag name on chrome://flagsNone
>
> Finch feature nameCSSCustomStateDeprecatedSyntax
>
> Requires code in //chrome?False
>
> Tracking bughttps://issues.chromium.org/issues/41486953
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5140610730426368?gate=4940354997714944
>
> Links to previous Intent discussions
> https://groups.google.com/a/chromium.org/g/blink-dev/c/JvpHoUfhJYE/m/uRtWiqoHAQAJ
>
> 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/CAK6btwKTMe%3DDOHsX%2Bs6PH%2BO6w0sJ7ZtS6jL%2BGV%2B958ZXLux_Ew%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/CADsXd2NdFixiU3%2BiOQDqdvtG%3DhzOZEFqarcPdf%3DQspXsP55oAw%40mail.gmail.com.

Re: [blink-dev] Unable to write Serialized SkPicture into a File

['Vladimir Levin' via blink-dev]

Hey Steven,

The path to convert information necessary for rendering into SkPictures may
or may not exist in the Chromium codebase, but it's certainly not actively
maintained or developed. Ultimately all information is available, but it
may come from several different sources.

For images, for example, it's likely that the Skia information stores them
in an encoded format backed by one of the decoders in Blink. The cc
codebase has classes that extracts the encoded information and schedules
decoding and upload which is then rasterized and presented as necessary. It
isn't necessarily trivial to convert this whole process to a few Skia
commands, and largely depends on what you're looking to accomplish.

Here's a thread from skia-discuss@ roughly talking about the same thing:
https://groups.google.com/g/skia-discuss/c/hd1ZCRkM4OA. As Brian mentions
there, SkPictures are an important primitive (as are other Skia commands)
but it's not the only thing. Chromium uses display lists and paint ops to
draw its contents. You can probably look at the serialization code as the
closest thing that does all the right serialization (this is used in Out of
Process Rasterization):
https://source.chromium.org/chromium/chromium/src/+/main:cc/paint/paint_op_buffer_serializer.h;l=21;drc=e09826065bb5964f247be565890dcabda54ac9e3.
As I mentioned previously in a different thread, this won't help you with
images. Those need to be either decoded and serialized or serialized in
encoded form and dealt with on the client side.

As Ken also mentioned, graphics-dev (and also skia-discuss) may be better
forums for this type of discussion

Thanks,
Vlad

On Mon, May 6, 2024 at 3:32 AM Steven Whelan 
wrote:

> Hi,
> Also found out that through paint_op_helper's tostring method
> 
> , all the PaintOps related information can be printed. It includes all the
> information- coordinates, paint info etc.
> Wondering, can these be converted directly into SKIA commands to render
> the page?
> Please help me finalize the correct approach.
>
>
> On Sun, May 5, 2024 at 3:49 AM Ken Russell  wrote:
>
>> I'm not sure exactly how SkPicture recording works - please join
>> https://groups.google.com/a/chromium.org/g/graphics-dev and email
>> graphics-...@chromium.org .
>>
>> -Ken
>>
>>
>>
>> On Sat, May 4, 2024 at 6:21 AM Steven Whelan 
>> wrote:
>>
>>> Hi I am able to write the serialized SKData (captured from Serialize
>>> method of  paint_op_buffer_serializer
>>> 
>>>  as
>>> shown in the first mail) to a file and was also able to use this file for
>>> playback on canvas.
>>> However, it only played back the text. How do I ensure that images also
>>> get captured in my SKPicture recording? Do I have to have multiple
>>> SKPictureRecording at multiple places?
>>> Goal : To record everything being written on a canvas while loading  a
>>> page so that it can be played back on another browser.
>>>
>>> Thanks
>>>
>>>
>>>
>>>
>>> On Thursday, May 2, 2024 at 5:34:48 AM UTC+5:30 k...@chromium.org wrote:
>>>
 Yes - you can confirm this yourself - but we strongly recommend against
 disabling the renderer sandbox.


 On Tue, Apr 30, 2024 at 10:46 PM Steven Whelan 
 wrote:

> Yes, trying to do this in renderer process. Would it work if I run
> Chromium with --nosandbox flag.
>
> On Tue, Apr 30, 2024, 21:58 Ken Russell  wrote:
>
>> Are you trying to do this within Chrome's renderer or GPU processes?
>> If so, the sandbox will prevent you from touching the local disk. You 
>> would
>> need to extend the sandbox policies to allow writing to a directory on 
>> disk
>> - some place that will not collide with other programs, so that if a bad
>> actor causes data to be written to that directory, no harm will be 
>> caused.
>> See
>> https://source.chromium.org/chromium/chromium/src/+/main:sandbox/policy/mac/
>> for the macOS sandbox policies.
>>
>> -Ken
>>
>>
>>
>> On Tue, Apr 30, 2024 at 8:59 AM Steven Whelan 
>> wrote:
>>
>>> Hi
>>> I have modified the Serialize
>>> 
>>>  method
>>> to Record all PaintOp as SKPicture.
>>> I want to replay this SKPicture on a remote browser. So, I am trying
>>> to save this SKPicture to a file, but I am not able to do so, since
>>> file.isOpen gives false.
>>> Please help here
>>>
>>> void PaintOpBufferSerializer::Serialize(const PaintOpBuffer& buffer,
>>> 

Re: [blink-dev] Intent to Extend Experiment: Capture all screens

['Vladimir Levin' via blink-dev]

On Mon, Mar 18, 2024 at 11:17 AM 'Simon Hangl' via blink-dev <
blink-dev@chromium.org> wrote:

> Hello blink-dev,
>
> We’d like to ask for an extension to our Origin Trial, from M124 to M130.
> This is due to a dependency on isolated web apps, which are delayed.
>

The intent process only allows extensions of 3 milestones at a time. It
also requires evidence of substantial progress on the feature. It sounds
like here, the original experiment did not go as planned due to a
dependency. Do you know if the isolated web apps feature is ready now? In
other words, is this dependency satisfied?


> Contact emails
>
> simo...@google.com
>
> Explainer
>
> https://github.com/screen-share/capture-all-screens/blob/main/README.md
>
> Specification
>
> https://screen-share.github.io/capture-all-screens
>
> Design docs
>
> https://screen-share.github.io/capture-all-screens
>
> https://github.com/screen-share/capture-all-screens/blob/main/README.md
>
>
> https://docs.google.com/document/d/13el0NriAUpAzLUw96V7zQiMSjgH9zVaTXUHtuaq8-HI/edit?resourcekey=0-jRPpeLth1odq6M5iFLswig
>
> Summary
>
> Capture all the screens currently connected to the device using
> getAllScreensMedia(). Calling getDisplayMedia() multiple times requires
> multiple user gestures, burdens the user with choosing the next screen each
> time, and does not guarantee to the app that all the screens were selected.
> getAllScreensMedia() improves on all of these fronts. (As this feature has
> extreme privacy ramifications, it is only exposed behind an enterprise
> policy, and users are warned before recording even starts, that recording
> *could* start at some point.)
>
>
> Blink component
>
> Blink>GetDisplayMediaSet
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/856
>
> TAG review status
>
> Complete
>
> Chromium Trial Name
>
> GetAllScreensMedia
>
> Link to origin trial feedback summary
>
> https://github.com/screen-share/capture-all-screens/issues
>
> Origin Trial documentation link
>
> https://github.com/screen-share/capture-all-screens
>
> Risks
>
> Interoperability and Compatibility
>
> This API is only available to origins allowlisted by administrators
> through a policy. The policy itself is non-standard, limiting even
> theoretical interoperability.This API rejects requests from pages that are
> not allow-listed through an administrator. The likelihood of this API being
> adopted by a browser that does not provide administrators mechanisms to
> manage clients is low.
>
>
> Gecko: N/A
>
> WebKit: N/A
>
> Web developers: Positive (
> https://github.com/screen-share/capture-all-screens/issues/9)
>
> Other signals:
>
> Ergonomics
>
> No
>
>
> Activation
>
> The challenge for developers is the limitation of the API to origins
> allowlisted by an enterprise policy.
>
>
> Security
>
> 1. Risk of malicious sites exploiting the API and gaining access to
> sensitive information on users' devices. This risk is mitigated by the API
> only being accessible to origins allowlisted by an enterprise policy.
>
>
> 2. Risk of users loading private information that gets recorded and made
> available to apps affiliated with their device's admin. This risk is
> mitigated by informing users that recording might start at any moment
> before the API becomes accessible. (In CrOS, this warning is delivered in
> the log-in screen, and when users log-in despite the warning, this is
> tantamount to assent.)
>
>
> 3. Risk of users forgetting that their screens are being recorded. This
> risk is mitigated through a persistent notification.
>
>
>
> Goals for experimentation
>
> Learn about the experience of web developers and how this API fulfills
> their needs.
>
> Reason this experiment is being extended
>
> This API will eventually be released for isolated contexts, which are
> delayed. Hence, we are asking for an extension of the origin trial.
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, ChromeOS, Android, and Android WebView)?
>
> No
>
> This API is initially implemented on CrOS, where demand for it is
> greatest, and where we have the most flexibility in offering users early
> warning that their screens may be recorded if they proceed past the log-in
> screen. Lessons learned from shipping this API on CrOS will be used when
> deciding how to correctly implement such warnings on other platforms.
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> No, as WPTs don’t support setting of managed policies. The API is tested
> by a number of unit- and browser- tests (Test files
> 
> ).
>
> DevTrial instructions
>
> https://github.com/screen-share/capture-all-screens/blob/main/HOWTO.md
>
> Flag name on chrome://flags
>
> enable-get-all-screens-media
>
> 

Re: [blink-dev] Intent to Ship: Compute Pressure

['Vladimir Levin' via blink-dev]

Asking as a user, the spec draft recommends
 that user
agents...

... show some form of user-visible notification that informs the user when
> a pressure observer is active, as well as provides the user with the means
> to block the ongoing operation ...


Do you know if this recommendation has been implemented? Also, is there a
permission prompt for this feature?

Thanks!
Vlad

-- 
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/CADsXd2NBot8b-pTZLXQer%3DR-w%3D8uuzqbC2LP5VbWx-0ByCFyhw%40mail.gmail.com.

Re: [blink-dev] Re: Intent to Ship: setHTMLUnsafe and parseHTMLUnsafe

['Vladimir Levin' via blink-dev]

On Wed, Feb 14, 2024 at 1:53 PM Jeffrey Yasskin 
wrote:

> Non-API-owner opinions inline:
>
> On Wed, Feb 14, 2024 at 1:42 PM 'Vladimir Levin' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> I just had some clarifying questions
>>
>> On Wed, Feb 14, 2024 at 1:13 PM Joey Arhar  wrote:
>>
>>> Some additional notes:
>>> - This API is tested in the declarative ShadowDOM tests in interop2024,
>>> and it is counting against us to not have it enabled by default.
>>> - The future sanitization options will be added as an optional second
>>> parameter to both methods, so there will not be any compat issues with
>>> shipping now.
>>>
>>> On Wed, Feb 14, 2024 at 1:11 PM Joey Arhar  wrote:
>>>
>>>> Contact emailsjar...@chromium.org
>>>>
>>>> ExplainerNone
>>>>
>>>
>> Is this the relevant explainer (referenced from the PR below):
>> https://github.com/WICG/sanitizer-api/blob/main/explainer.md
>>
>>
>>>
>>>>
>>>> Specification
>>>> https://html.spec.whatwg.org/C/#unsafe-html-parsing-methods
>>>> https://github.com/whatwg/html/pull/9538
>>>>
>>>> Summary
>>>>
>>>> The setHTMLUnsafe and parseHTMLUnsafe methods allow Declarative
>>>> ShadowDOM to be used from javascript. In the future, they may also get new
>>>> parameters for sanitization.
>>>>
>>>>
>>>> Blink componentBlink>HTML
>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EHTML>
>>>>
>>>> TAG reviewNone
>>>>
>>>> TAG review statusNot applicable
>>>>
>>>
>> There seems to be consensus within browser vendors that this is a good
>> idea, but I'm just wondering why you decided against filing TAG here?
>>
>
> IMO, either Firefox or Safari folks should have filed a TAG review for
> this before they merged their patches. Now that they've merged, I think it
> falls into the "[already specified && already shipped]" exception category
> <https://www.chromium.org/blink/guidelines/api-owners/process-exceptions/>,
> and it's probably too fixed to ask the TAG to spend time on it.
>

(also non-api-owner, but responding anyway): if that is in fact shipping
then I agree that this should be the exception here, thanks.


>
>> Risks
>>>>
>>>>
>>>> Interoperability and Compatibility
>>>>
>>>> None
>>>>
>>>>
>>>> *Gecko*: No signal (
>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1850675)
>>>> https://github.com/whatwg/html/pull/9538#issuecomment-1728947778
>>>>
>>>
>> This seems positive, right?
>>
>
>
>> *WebKit*: Positive (https://bugs.webkit.org/show_bug.cgi?id=261143)
>>>>
>>>
>> I'm not sure how to read this properly, but is this a positive signal or
>> "shipped/shipping" signal?
>>
>
> Both of these look like "Shipped/Shipping", per
> https://bit.ly/blink-signals. That status is a little odd, because it
> doesn't look like they've actually made it to a stable release, but if I'm
> reading the bug trackers right they're both merged, so they're past "In
> Development".
>

Yeah, that's my thought here too. My understanding is that all of the
patches here are merged, but I just wanted to double check in case I'm
misunderstanding what those bugs are implying.


>
>
>> *Web developers*: No signals
>>>>
>>>> *Other signals*:
>>>>
>>>> Ergonomics
>>>>
>>>> This API will likely be used in tandem with Declarative ShadowDOM. The
>>>> default usage of this API will not make it hard for chrome to maintain good
>>>> performance.
>>>>
>>>>
>>>> Activation
>>>>
>>>> It will not be challenging for developers to use this feature
>>>> immediately.
>>>>
>>>>
>>>> Security
>>>>
>>>> There are no security risks. This API just does declarative ShadowDOM.
>>>> There is an "unsafe" in the name because there are future plans to add
>>>> sanitization options. https://github.com/WICG/sanitizer-api/issues/185
>>>> https://github.com/whatwg/html/issues/8627
>>>> https://github.com/whatwg/html/issues/8759
>>>>
>>>>
>>>> WebView application risks
>>>>
>>

Re: [blink-dev] Re: Intent to Ship: setHTMLUnsafe and parseHTMLUnsafe

['Vladimir Levin' via blink-dev]

I just had some clarifying questions

On Wed, Feb 14, 2024 at 1:13 PM Joey Arhar  wrote:

> Some additional notes:
> - This API is tested in the declarative ShadowDOM tests in interop2024,
> and it is counting against us to not have it enabled by default.
> - The future sanitization options will be added as an optional second
> parameter to both methods, so there will not be any compat issues with
> shipping now.
>
> On Wed, Feb 14, 2024 at 1:11 PM Joey Arhar  wrote:
>
>> Contact emailsjar...@chromium.org
>>
>> ExplainerNone
>>
>
Is this the relevant explainer (referenced from the PR below):
https://github.com/WICG/sanitizer-api/blob/main/explainer.md


>
>>
>> Specificationhttps://html.spec.whatwg.org/C/#unsafe-html-parsing-methods
>> https://github.com/whatwg/html/pull/9538
>>
>> Summary
>>
>> The setHTMLUnsafe and parseHTMLUnsafe methods allow Declarative ShadowDOM
>> to be used from javascript. In the future, they may also get new parameters
>> for sanitization.
>>
>>
>> Blink componentBlink>HTML
>> 
>>
>> TAG reviewNone
>>
>> TAG review statusNot applicable
>>
>
There seems to be consensus within browser vendors that this is a good
idea, but I'm just wondering why you decided against filing TAG here?


>
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> None
>>
>>
>> *Gecko*: No signal (https://bugzilla.mozilla.org/show_bug.cgi?id=1850675
>> ) https://github.com/whatwg/html/pull/9538#issuecomment-1728947778
>>
>
This seems positive, right?

>
>>
>> *WebKit*: Positive (https://bugs.webkit.org/show_bug.cgi?id=261143)
>>
>
I'm not sure how to read this properly, but is this a positive signal or
"shipped/shipping" signal?


>
>> *Web developers*: No signals
>>
>> *Other signals*:
>>
>> Ergonomics
>>
>> This API will likely be used in tandem with Declarative ShadowDOM. The
>> default usage of this API will not make it hard for chrome to maintain good
>> performance.
>>
>>
>> Activation
>>
>> It will not be challenging for developers to use this feature immediately.
>>
>>
>> Security
>>
>> There are no security risks. This API just does declarative ShadowDOM.
>> There is an "unsafe" in the name because there are future plans to add
>> sanitization options. https://github.com/WICG/sanitizer-api/issues/185
>> https://github.com/whatwg/html/issues/8627
>> https://github.com/whatwg/html/issues/8759
>>
>>
>> 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
>>
>> This API does not need any special DevTools features. You can call the
>> method from the console panel.
>>
>>
>> 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://flagsHTMLUnsafeMethods
>>
>> Finch feature nameHTMLUnsafeMethods
>>
>> Requires code in //chrome?False
>>
>> Estimated milestones
>> DevTrial on desktop 120
>> DevTrial on Android 120
>>
>> 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/6560361081995264
>>
>> 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/CAK6btwJiEbhk_YGbVhuUg0emSJTfT%3D20_1bTDMFJxcH5i9tbMQ%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/CADsXd2MH_fZddPf6c_QwhEP5JU767nEy1ck338Cx_HYFsytO4w%40mail.gmail.com.

Re: [blink-dev] Request for Deprecation Trial: Deprecate Mutation Events

['Vladimir Levin' via blink-dev]

On Thu, Feb 1, 2024 at 6:30 PM Mason Freed  wrote:

>
> On Thu, Feb 1, 2024 at 7:12 AM Vladimir Levin  wrote:
>
>> This is very exciting! Thank you for working on this.
>>
>
> Thanks!
>
>
>> Do you know whether the existing usage is feature checked? 1.58% seems
>> very high, but if it's feature checked and fallback is something like
>> mutation observer, then it would be a lot more safe imho. Also, do you have
>> a sense of where the usage is coming from (a few large frameworks vs a ton
>> of smaller sites)?
>>
>
> Unfortunately, I haven't seen a lot of feature checking around mutation
> events directly. I have definitely seen feature checks on MutationObserver
> that then avoids trying to use mutation events. But obviously those aren't
> part of the use counter data, since they don't attach mutation
> event listeners.
>
> I've been looking into UKM data to see if I can suss out any large usage
> patterns. I've found a few, e.g. QuillJS
> , which contribute a
> significant chunk of usage to many sites. Thankfully in the cases I've
> seen, the (large) deprecation warnings I've added to Chrome seem to be doing
> their thing
> .
> My hope is that direct outreach (which I've done in a few cases), heavy
> warnings, and eventually the start of the removal effort (plus this OT to
> give sites an extension) will nudge the remaining users to migrate.
>

It's good to know that QuillJS seems to be addressing their issue in 2.0,
although the currently published stable version is still 1.x. I just wanted
to verify the timeline for disabling these features. The trial is for
124-134 and the feature will be turned off by default in 127. Sounds
reasonable to me, but I'd encourage checking whether QuillJS ships to 2.0
in the 127 timeframe :)


>
>>  The npm package you listed, for example, would use the actual events if
>> available, so sites using that polyfill would also count towards the event
>> usage if the browser supports those even though that's "safe", right?
>>
>
> This is an excellent point that I hadn't thought of. I'm going to modify
> the polyfill right now to *always* run. That way polyfilled usage will no
> longer be counted. I'm used to writing polyfills for features that are
> getting *added*, where you want to avoid using the polyfill when the
> feature is supported. This is the opposite.
>
> Thanks,
> Mason
>
>
>
>>>
>>> *Gecko*: Positive (
>>> https://github.com/mozilla/standards-positions/issues/807) "very strong
>>> positive position"
>>>
>>> *WebKit*: No signal (
>>> https://github.com/WebKit/standards-positions/issues/192)
>>>
>>> *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 experimentation
>>>
>>>
>>>
>>> Ongoing technical constraints
>>>
>>>
>>>
>>> Debuggability
>>>
>>>
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, ChromeOS, Android, and Android WebView)?Yes
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?No
>>>
>>> Flag name on chrome://flags
>>>
>>> Finch feature nameNone
>>>
>>> Non-finch justificationNone
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bughttps://crbug.com/1446498
>>>
>>> Estimated milestones
>>> Shipping on desktop 115
>>> OriginTrial desktop last 134
>>> OriginTrial desktop first 124
>>> Shipping on Android 115
>>> OriginTrial Android last 134
>>> OriginTrial Android first 124
>>> Shipping on WebView 115
>>> OriginTrial webView last 134
>>> OriginTrial webView first 124
>>>
>>> Link to entry on the Chrome Platform Status
>>> https://chromestatus.com/feature/5083947249172480
>>>
>>> Links to previous Intent discussionsIntent to Experiment:
>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/qDsKRU-cQ_4/m/isA1mZ_aAAAJ
>>>
>>>
>>> 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/CAM%3DNeDjevtANjMn1NUK83UGyJyv4HrLCFkjs9fhL6UVov_uAkA%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 

Re: [blink-dev] Request for Deprecation Trial: Deprecate Mutation Events

['Vladimir Levin' via blink-dev]

On Wed, Jan 31, 2024 at 8:54 PM Mason Freed  wrote:

> Contact emailsmas...@chromium.org
>
> ExplainerNone
>
> Specificationhttps://w3c.github.io/uievents/#legacy-event-types
>
> Summary
>
> Mutation Events, including `DOMSubtreeModified`, `DOMNodeInserted`,
> `DOMNodeRemoved`, `DOMNodeRemovedFromDocument`,
> `DOMNodeInsertedIntoDocument`, and `DOMCharacterDataModified`, are quite
> bad for page performance, and also significantly increase the complexity of
> adding new features to the Web. These APIs were deprecated from the spec (
> https://w3c.github.io/uievents/#legacy-event-types) in 2011, and were
> replaced (in 2012) by the much better-behaved Mutation Observer API. Usage
> of the obsolete Mutation Events must be migrated to Mutation Observer.
> Mutation events are deprecated starting in Chrome 115, and support will be
> disabled by default starting in Chrome 127, around July 30, 2024. A
> Deprecation Trial will be available starting in Chrome 124, and extending
> through Chrome 134, which can be used to extend the time a site has to
> migrate by ~9 months, until March 25, 2025.
>

>
> Blink componentBlink>DOM
> 
>
> Search tagsMutationEvent
> , DOMSubtreeModified
> ,
> DOMNodeInserted ,
> DOMNodeRemoved ,
> DOMNodeRemovedFromDocument
> ,
> DOMNodeInsertedIntoDocument
> ,
> DOMCharacterDataModified
> 
>
> TAG reviewNone
>
> TAG review statusNot applicable
>
> Chromium Trial NameMutationEvents
>
> Origin Trial documentation link
> https://developer.chrome.com/blog/mutation-events-deprecation
>
> WebFeature UseCounter namekDOMNodeRemovedEvent
>
> Risks
>
>
> Interoperability and Compatibility
>
> There are technically 9 Mutation Events, but Chromium only implements 6 of
> them. Their use counters vary significantly: - DOMNodeInsertedIntoDocument:
> 0.006% - DOMNodeRemovedFromDocument: 0.012% - DOMCharacterDataModified:
> 0.016% - DOMNodeRemoved: 0.77% - DOMSubtreeModified: 0.81% -
> DOMNodeInserted: 1.58% The DOMNodeInsertedIntoDocument and
> DOMNodeRemovedFromDocument events are not fired by Gecko. That, plus the
> low use counters for those two plus DOMCharacterDataModified, mean that
> these three could likely be fairly easily removed after some time. The last
> three have quite significant usage, and more study and outreach will be
> required to bring this usage down below safe removal limits, which will
> take significant time. Tentatively, we're aiming for M126 as the last
> version of Chrome that supports the events above, ending July 30, 2024.
> This npm package attempts to polyfill Mutation Events using Mutation
> Observer: https://www.npmjs.com/package/mutation-events.
>

This is very exciting! Thank you for working on this.

Do you know whether the existing usage is feature checked? 1.58% seems very
high, but if it's feature checked and fallback is something like mutation
observer, then it would be a lot more safe imho. Also, do you have a sense
of where the usage is coming from (a few large frameworks vs a ton of
smaller sites)? The npm package you listed, for example, would use the
actual events if available, so sites using that polyfill would also count
towards the event usage if the browser supports those even though that's
"safe", right?


>
> *Gecko*: Positive (
> https://github.com/mozilla/standards-positions/issues/807) "very strong
> positive position"
>
> *WebKit*: No signal (
> https://github.com/WebKit/standards-positions/issues/192)
>
> *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 experimentation
>
>
>
> Ongoing technical constraints
>
>
>
> Debuggability
>
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, ChromeOS, Android, and Android WebView)?Yes
>
> Is this feature fully tested by web-platform-tests
> 
> ?No
>
> Flag name on chrome://flags
>
> Finch feature nameNone
>
> Non-finch justificationNone
>
> Requires code in //chrome?False
>
> Tracking bughttps://crbug.com/1446498
>
> Estimated milestones
> Shipping on desktop 115
> OriginTrial desktop last 134
> OriginTrial desktop first 124
> Shipping on Android 115
> OriginTrial Android last 134
> OriginTrial Android first 124
> Shipping on WebView 115
> OriginTrial webView last 134
> OriginTrial webView 

Re: [blink-dev] Intent to Ship: Element Reflection

['Vladimir Levin' via blink-dev]

On Wed, Jan 31, 2024 at 6:14 PM Alice Boxhall  wrote:

>
>
> On Thursday, February 1, 2024 at 6:52:13 AM UTC+11 vmp...@google.com
> wrote:
>
> On Wed, Jan 31, 2024 at 10:10 AM alice  wrote:
>
> Contact emails
> al...@igalia.com, mere...@chromium.org
>
> Explainer
>
> https://github.com/WICG/aom/blob/gh-pages/aria-reflection-explainer.md#reflecting-element-references
>
> Specification
>
> https://html.spec.whatwg.org/multipage/common-dom-interfaces.html#reflecting-content-attributes-in-idl-attributes:element
> https://w3c.github.io/aria/#ARIAMixin
>
> Summary
> This feature allows for ARIA relationship attributes to be reflected in
> IDL as element references rather than DOMStrings.
>
> Note: This intent specifically concerns the ARIA attributes using
> Element Reflection, i.e. the attributes in the ARIAMixin interface with
> a type of Element or FrozenArray. popoverTargetElement, which
> also uses Element Reflection, is already shipping in Blink and WebKit.
>
> Blink component
> Blink>DOM
>
> TAG review
> https://github.com/w3ctag/design-reviews/issues/134
>
> TAG review status
> Issues addressed
>
> Risks
>
> Interoperability and Compatibility
>
> Gecko: Under consideration
> https://github.com/mozilla/standards-positions/issues/200
> https://bugzilla.mozilla.org/show_bug.cgi?id=1769586
>
> WebKit: Shipped/Shipping
> (
> https://developer.apple.com/documentation/safari-technology-preview-release-notes/stp-release-151
> )
> Mentioned in STP release notes:
>
> https://developer.apple.com/documentation/safari-technology-preview-release-notes/stp-release-151
> Was shipped in Safari 16.4 but wasn't mentioned in release notes there.
>
> Web developers: Requested by Web Component authors in particular as a
> means to implement ARIA relationships for elements inside of Shadow DOM.
>
>
> I wonder if you had any feedback from framework authors that use VDOM. For
> context, we were considering using element references for a different
> feature, and couldn't overcome the fact that when frameworks change DOM,
> sometimes Nodes and Elements are removed or reused for a different purpose
> than when initially constructed (ie the element that used to represent the
> first item in the list is now used to represent the third item in the list).
>
> I realize that this is asking a question very late in the design process,
> but I'm just curious if that's a case that you considered and if so how you
> reasoned about it.
>
>
> To be honest, no, we didn't take VDOM into account.
>
> I'd be curious to hear what specific cases you were running into
> difficulty with, but it does seem like these paradigms are fundamentally at
> odds with one another - if elements are unpredictably destroyed and
> recreated, then it seems like using the string ID-based version is going to
> be a better fit. This API is, at least, designed to work with using the
> `setAttribute()` version, in that setting the content attribute will cause
> any value set via the IDL attribute to be discarded (and vice-versa).
>

The main use case for us was just matching elements automatically across
DOM mutations with a caveat that we were using CSS, not attributes. We
couldn't really get a sense of how stable our proposals were because of the
VDOM type of reordering. It might be worthwhile for us to revisit that
plan. I agree with you that I think your case is a lot better, since it
affects attributes being set, instead of being some ephemeral state that
the browser keeps track of.


>
> (VDOM has always made me anxious for similar reasons - if elements are
> unpredictably moved or destroyed, what happens if an assistive technology
> was visiting those nodes in the accessibility tree when that happens? But I
> have essentially no experience actually using it, so presumably that can be
> managed in practice.)
>

I also agree with this sentiment. It seems like we want to rely on the
persistence of elements and their identity, but at the same time there are
a lot of optimized frameworks that are fast because they don't.




>
>
> Activation
> This feature is not completely polyfillable; ID references across shadow
> root boundaries are not possible to implement on top of existing APIs.
>
> WebView application risks
> None
>
> Debuggability
> Developers can use console.log to access the value for IDL attributes
> set via this API, and the Accessibility pane to confirm that the
> attributes are correctly reflected in the accessibility tree.
>
> 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?
> https://wpt.fyi/results/html/dom/aria-element-reflection.html tests that
> the reflection part of the API works correctly.
> WPT doesn't yet offer a way to test the relevant accessibility tree
> mappings.
>
> Flag name on chrome://flags
> None
>
> Finch feature name
> None
>
> Non-finch justification
> None
>
> Requires code in //chrome?
> False

Re: [blink-dev] Intent to Ship: Element Reflection

['Vladimir Levin' via blink-dev]

On Wed, Jan 31, 2024 at 10:10 AM alice  wrote:

> Contact emails
> al...@igalia.com, meredi...@chromium.org
>
> Explainer
>
> https://github.com/WICG/aom/blob/gh-pages/aria-reflection-explainer.md#reflecting-element-references
>
> Specification
>
> https://html.spec.whatwg.org/multipage/common-dom-interfaces.html#reflecting-content-attributes-in-idl-attributes:element
> https://w3c.github.io/aria/#ARIAMixin
>
> Summary
> This feature allows for ARIA relationship attributes to be reflected in
> IDL as element references rather than DOMStrings.
>
> Note: This intent specifically concerns the ARIA attributes using
> Element Reflection, i.e. the attributes in the ARIAMixin interface with
> a type of Element or FrozenArray. popoverTargetElement, which
> also uses Element Reflection, is already shipping in Blink and WebKit.
>
> Blink component
> Blink>DOM
>
> TAG review
> https://github.com/w3ctag/design-reviews/issues/134
>
> TAG review status
> Issues addressed
>
> Risks
>
> Interoperability and Compatibility
>
> Gecko: Under consideration
> https://github.com/mozilla/standards-positions/issues/200
> https://bugzilla.mozilla.org/show_bug.cgi?id=1769586
>
> WebKit: Shipped/Shipping
> (
> https://developer.apple.com/documentation/safari-technology-preview-release-notes/stp-release-151
> )
> Mentioned in STP release notes:
>
> https://developer.apple.com/documentation/safari-technology-preview-release-notes/stp-release-151
> Was shipped in Safari 16.4 but wasn't mentioned in release notes there.
>
> Web developers: Requested by Web Component authors in particular as a
> means to implement ARIA relationships for elements inside of Shadow DOM.
>

I wonder if you had any feedback from framework authors that use VDOM. For
context, we were considering using element references for a different
feature, and couldn't overcome the fact that when frameworks change DOM,
sometimes Nodes and Elements are removed or reused for a different purpose
than when initially constructed (ie the element that used to represent the
first item in the list is now used to represent the third item in the list).

I realize that this is asking a question very late in the design process,
but I'm just curious if that's a case that you considered and if so how you
reasoned about it.


> Activation
> This feature is not completely polyfillable; ID references across shadow
> root boundaries are not possible to implement on top of existing APIs.
>
> WebView application risks
> None
>
> Debuggability
> Developers can use console.log to access the value for IDL attributes
> set via this API, and the Accessibility pane to confirm that the
> attributes are correctly reflected in the accessibility tree.
>
> 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?
> https://wpt.fyi/results/html/dom/aria-element-reflection.html tests that
> the reflection part of the API works correctly.
> WPT doesn't yet offer a way to test the relevant accessibility tree
> mappings.
>
> Flag name on chrome://flags
> None
>
> Finch feature name
> None
>
> Non-finch justification
> None
>
> Requires code in //chrome?
> False
>
> Tracking bug
> https://crbug.com/981423
>
> Measurement
> Per-attribute UseCounters:
> V8Element_AriaActiveDescendantElement_AttributeGetter
> V8Element_AriaActiveDescendantElement_AttributeSetter
> V8Element_AriaControlsElements_AttributeGetter
> V8Element_AriaControlsElements_AttributeSetter (etc)
>
> V8ElementInternals_AriaActiveDescendantElement_AttributeGetter
> V8ElementInternals_AriaActiveDescendantElement_AttributeSetter
> V8ElementInternals_AriaControlsElements_AttributeGetter
> V8ElementInternals_AriaControlsElements_AttributeSetter (etc)
>
> Estimated milestones
> 123 or 124
>
> Anticipated spec changes
> None
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/6244885579431936
>
> Links to previous Intent discussions
> Ready for Trial:
>
> https://groups.google.com/a/chromium.org/g/blink-dev/c/yecxBLmRVQI/m/d7YOe_nYAgAJ
>
> --
> 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/865bf3bd2e6a58da9fc3424ed957ceee%40igalia.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/CADsXd2N%3DNU1EUUi6jSEwjoH6Vmo9qGOK82bpWMzB%2BniE4tC_3g%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Private Network Access permission to relax mixed content

['Vladimir Levin' via blink-dev]

On Fri, Jan 26, 2024 at 5:07 AM 'Yifan Luo' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emails...@chromium.org, cl...@chromium.org
>
> Explainer
> https://github.com/WICG/private-network-access/blob/main/permission_prompt/explainer.md
>
> Specificationhttps://wicg.github.io/private-network-access
>
> Design docs
>
> https://docs.google.com/document/d/1Q18g4fZoDIYQ9IuxlZTaItgkzfiz_tCqaEAI8J3Y1WY/edit
>
> https://github.com/WICG/private-network-access/blob/main/permission_prompt/security_privacy_self_review.md
>
> Summary
>
> In order to establish connections to devices on a local network that do
> not have globally unique names, and therefore cannot obtain TLS
> certificates, this feature introduces a new option to `fetch()` to declare
> a developers' intent to talk to such a device, a new policy-controlled
> feature to gate each sites' access to this capability, and new headers for
> the server's preflight response to provide additional metadata.
>
>
> Blink componentBlink>SecurityFeature>CORS>PrivateNetworkAccess
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/751
>
> TAG review statusIssues addressed
>
> Chromium Trial NamePrivateNetworkAccessPermissionPrompt
>
> Origin Trial documentation link
> https://github.com/WICG/private-network-access/blob/main/permission_prompt/explainer.md
>
> WebFeature UseCounter namekPrivateNetworkAccessPermissionPrompt
>
> Risks
>
>
> Interoperability and Compatibility
>
>
>
> *Gecko*: No signal
>
> *WebKit*: No signal
>

Could you file RFPs for this?


>
> *Web developers*: Positive (
> https://github.com/WICG/private-network-access/issues/23)
>
> *Other signals*:
>
> Ergonomics
>
> This new feature requires users to click on the new permission. This may
> lead users to spamming on some websites. However, this is an intentional
> move to encourage the websites to provide security context. The origin
> trial also aimed to measure the frequency of users getting the permissions.
>

Apologies if I missed this, but is there a document somewhere summarizing
the OT findings?


>
>
> Activation
>
> No. This feature attempt to bring developers an easier way to restrict
> Private Network Access with secure context.
>
>
> Security
>
> This is a security positive feature.
>
>
> 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
>
> Relevant information (client and resource IP address space) is already
> piped into the DevTools network panel. We’ll likely also represent the
> permission state in the settings pages.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, ChromeOS, Android, and Android WebView)?No
>
> Mac, Windows, Linux, Chrome OS, Fuchsia, Android, WebLayer. Not Android
> WebView because of the absence of deprecation trial integration (though
> that may be changing soon, see https://crbug.com/1308425). Not iOS
> because this requires changes in Blink and the network service, neither of
> which are used on iOS.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?No
>
>
> https://wpt.fyi/results/fetch/private-network-access/mixed-content-fetch.tentative.https.window.html?label=master=experimental=private-network-access
>
>

>
> Flag name on chrome://flags
>
> Finch feature nameNone
>
> Non-finch justificationNone
>

Does this mean the feature is not flag guarded, or is this just an omission
in chromestatus?

>
>

>
> Requires code in //chrome?True
>
> Tracking bughttps://crbug.com/1338439
>
> Sample links
>
> https://drive.google.com/file/d/1pnyQfIsXdtJnZoCBVSt4xim0yXjZ0Aqc/view?usp=sharing
>
> Estimated milestones
> Shipping on desktop 123
> OriginTrial desktop last 122
> OriginTrial desktop first 120
> DevTrial on desktop 120
>
> 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/5954091755241472
>
> Links to previous Intent discussionsIntent to prototype:
> https://groups.google.com/a/chromium.org/g/blink-dev/c/6MczoSFGiHo/m/IigYuhu7AwAJ
>  Intent
> to Experiment:
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAG-zKU_ZS1ibT9H7e5UmoUF2OfCUq5ocsDHaCoJ2rShmPmAejQ%40mail.gmail.com
>
>
> This intent message was generated by Chrome Platform Status
> .
>
> --
> Yifan
>
> --
> You received this message 

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

['Vladimir Levin' via blink-dev]

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

> Contact emailsjap...@chromium.org, nrosent...@chromium.org
>
> Explainer
> https://github.com/WICG/view-transitions/blob/main/navigation-activation-explainer.md
>
> Specification
> https://html.spec.whatwg.org/multipage/nav-history-apis.html#navigation-activation-interface
>
> Summary
>
> navigation.activation stores state about when the current Document was
> activated (e.g., when it was initialized, or restored from the back/forward
> cache).
>
>
> Blink componentBlink>History
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/921
>
> TAG review statusIssues addressed
>
> Risks
>
>
> Interoperability and Compatibility
>
> None
>
>
> *Gecko*: Positive (
> https://github.com/mozilla/standards-positions/issues/928)
>
> *WebKit*: No signal (
> https://github.com/WebKit/standards-positions/issues/282)
>
> *Web developers*: Positive
>
> *Other signals*:
>
> Security
>
> This is a cross-document (navigation) feature, so designing it we needed
> to take care of cross-origin navigation related risks. Since
> `navigation.activation` is part of the navigation API, it uses the same
> semantics and protections. We only expose things that are otherwise exposed
> by the navigation API or in other means.
>
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?
>
> None
>
>
> Debuggability
>
> None
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, ChromeOS, Android, and Android WebView)?Yes
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes
>
>
> https://wpt.fyi/results/navigation-api/navigation-activation?label=master=experimental=navigation%20activation
>
>
> Flag name on chrome://flagsNavigationActivation
>
> Finch feature nameNone
>
> Non-finch justification
>
> It's a web-API, exposing it gradually doesn't make sense.
>

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

>
>
> Requires code in //chrome?False
>
> Estimated milestones
> Shipping on desktop 123
> Shipping on Android 123
> Shipping on WebView 123
> Shipping on WebView 123
>
> Anticipated spec changes
>
> Open questions about a feature may be a source of future web compat or
> interop issues. Please list open issues (e.g. links to known github issues
> in the project for the feature specification) whose resolution may
> introduce web compat/interop risk (e.g., changing to naming or structure of
> the API in a non-backward-compatible way).
> None
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5076557983121408
>
> Links to previous Intent discussionsIntent to prototype:
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACf%3D2LJa-_9cEjMU3Ds660KmW0u_G_M9S1Ah-14gAfk9Qhrp2g%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/CAJn%3DMYZLDnYwfav4o7vMLAWE9o_irDceWxKabqcpBbb4e4byDQ%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/CADsXd2MCMUjAyK5n-9%3D%3DR4EdbkVqcf9%2BwALHf9phaqG9iaxuww%40mail.gmail.com.

Re: [blink-dev] Intent to Deprecate non-standard declarative shadow DOM serialization

['Vladimir Levin' via blink-dev]

On Fri, Jan 19, 2024 at 7:54 PM Mason Freed  wrote:

>
>
> On Friday, January 19, 2024 at 12:27:50 PM UTC-8 vmp...@google.com wrote:
>
> Interoperability and Compatibility
>
> The use counter for getInnerHTML() (https://chromestatus.com/
> metrics/feature/timeline/popularity/3874) shows 0.04% of page loads using
> this function as of January 2024. That represents high usage for
> deprecation, however, the numbers were quite similar for the deprecation of
> the old `shadowroot` attribute, and the removal of that feature generated
> zero bug reports. It is my strong belief that since this feature is only
> shipped in Chrome, the vast majority of usage is guarded by feature checks.
> So this deprecation should be safer than it would seem from the numbers. My
> plan is to very slowly disable the API and monitor closely for bug reports.
> That approach was quite successful for the removal of shadowroot. If bugs
> are reported, I'll back off and make a new plan.
>
>
> I agree that I expect most uses to be feature checked. That being said,
> have you tried to figure out where the 0.04% is coming from? Is it a lot of
> small uses or a few big sites that keep using it? If it's the latter, it
> may be worth it to reach out.
>
>
> That's a good point. So I just took a look a the top 8 users from the use
> counter page
> . Of
> those, 2 do not contain any usage of getInnerHTML(). All 6 of the remainder
> come from one single library,  "Auryc JavaScript Client-Side Library". And
> that library a) already feature checks for declarative shadow DOM before
> using getInnerHTML(), and further b) feature checks the *old* `shadowroot`
> attribute. So I suspect the use counter is already overcounting the usage
> -  see this bug for why
> .
>

> Thanks for pushing on this - let me know if the above convinces you that
> the risk should be low.
>

Yeah, I think the risk is low here.

FWIW, I couldn't find any relevant github or contact info for this library
but if you had better luck finding contact information, we might as well
file an issue or send an email.


> Thanks,
> Mason
>
>
>
>
> *Gecko*: No signal
>
> *WebKit*: No signal
>
> *Web developers*: No signals
>
> *Other signals*:
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?
>
> None
>
>
> Debuggability
>
> None
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?No
>
> Flag name on chrome://flagsNone
>
> Finch feature nameNone
>
> Non-finch justificationNone
>
> Requires code in //chrome?False
>
> Tracking bughttps://crbug.com/1519972
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Statushttps://chromestatus.com/
> feature/5081733588582400
>
> This intent message was generated by me, manually, because of this bug
> .
>
> --
> 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/CAM%3DNeDhpHobDUy1VwZ2rmy5DBUVfsm8
> ijXOEtk%2B1eHjJgu6FRg%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/CADsXd2PfrHxBnr_u6Cc1T7-TtVnQM7RUNKV47zcsvRr7-jUuGg%40mail.gmail.com.

Re: [blink-dev] New API owner: Domenic Denicola

['Vladimir Levin' via blink-dev]

Congrats, Domenic!

On Fri, Jan 19, 2024 at 3:59 PM Rick Byers  wrote:

> Hi blink-dev,
> +Domenic Denicola  has volunteered to donate his
> time and considerable web platform expertise to reviewing intent threads as
> an API owner. Domenic is very active in the web standards community
> including as an HTML editor, runs our spec mentors
>  program and has
> contributed helpfully to a wide variety of intent discussions over the past
> year. His nomination
>  was
> reviewed and approved  by
> the existing API owners today.
>
> Thank you Domenic!
>Rick
>
> --
> 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/CAFUtAY-Zq2WDWz0_UhfweWd4e4c1dr8OTaCaLXiW289pNKfDDg%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/CADsXd2M%2BQ%2Bci3Eco1pPDmXzuyiz005dE64%2BAE_Qe-MTMLHX0nQ%40mail.gmail.com.

Re: [blink-dev] Intent to Deprecate non-standard declarative shadow DOM serialization

['Vladimir Levin' via blink-dev]

On Fri, Jan 19, 2024 at 3:13 PM Mason Freed  wrote:

> Contact emailsmas...@chromium.org
>
> Explainer
> https://github.com/whatwg/html/issues/8867#issuecomment-1856696628
>
> SpecificationNone
>
> Summary
>
> The prototype implementation (which was shipped in 2020 and then
> shape-changed in 2023) contained a method called `getInnerHTML()` that
> could be used to serialize DOM trees containing shadow roots. That part of
> the prototype was not standardized with the rest of declarative shadow dom,
> and only recently has it reached spec consensus (
> https://github.com/whatwg/html/issues/8867). As part of that consensus,
> the shape of the getInnerHTML API changed. This feature represents the
> deprecation of the old, shipped `getInnerHTML()` method. The replacement is
> called `getHTML()`: see
> https://chromestatus.com/guide/edit/5102952270528512.
>
> Blink componentBlink>DOM>ShadowDOM
> 
>
> Motivation
>
> The standardized method, getHTML(), has the chance at being interoperable,
> while this version (getInnerHTML) does not.
>
> Initial public proposal
> https://github.com/whatwg/html/issues/8867#issuecomment-1856696628
>
> TAG reviewNone
>
> TAG review statusPending
>
> Risks
>
>
> Interoperability and Compatibility
>
> The use counter for getInnerHTML() (
> https://chromestatus.com/metrics/feature/timeline/popularity/3874) shows
> 0.04% of page loads using this function as of January 2024. That represents
> high usage for deprecation, however, the numbers were quite similar for the
> deprecation of the old `shadowroot` attribute, and the removal of that
> feature generated zero bug reports. It is my strong belief that since this
> feature is only shipped in Chrome, the vast majority of usage is guarded by
> feature checks. So this deprecation should be safer than it would seem from
> the numbers. My plan is to very slowly disable the API and monitor closely
> for bug reports. That approach was quite successful for the removal of
> shadowroot. If bugs are reported, I'll back off and make a new plan.
>

I agree that I expect most uses to be feature checked. That being said,
have you tried to figure out where the 0.04% is coming from? Is it a lot of
small uses or a few big sites that keep using it? If it's the latter, it
may be worth it to reach out.


>
> *Gecko*: No signal
>
> *WebKit*: No signal
>
> *Web developers*: No signals
>
> *Other signals*:
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such that
> it has potentially high risk for Android WebView-based applications?
>
> None
>
>
> Debuggability
>
> None
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?No
>
> Flag name on chrome://flagsNone
>
> Finch feature nameNone
>
> Non-finch justificationNone
>
> Requires code in //chrome?False
>
> Tracking bughttps://crbug.com/1519972
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5081733588582400
>
> This intent message was generated by me, manually, because of this bug
> .
>
> --
> 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/CAM%3DNeDhpHobDUy1VwZ2rmy5DBUVfsm8ijXOEtk%2B1eHjJgu6FRg%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/CADsXd2P45gzFsjbBgpLpr3aNAYHH0HC%2BY7GEYfXSzw07L-tBkA%40mail.gmail.com.

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

['Vladimir Levin' via blink-dev]

Thank you for the detailed explanation. It's hard to decipher from meeting
notes whether a discussion is bikeshedding or serious objections :)

Based on your description, it does seem like there is good consensus

Thanks,
Vlad

On Fri, Jan 19, 2024 at 5:14 AM Henrik Boström  wrote:

> Having participated in both the WG meeting and the following editors
> meetings where the editors merged the PR, my memory too is that there was
> wide support for this.
>
> To make sure I'm not misremembering, I rewatching the recording
>  just now. I don't
> hear anybody challenging the use case, it's mostly discussions about
> whether this should be considered a "parameter" or not. Philipp explains
> why it needs to be set at the same time as the other parameters even though
> it's not a traditional parameter, Harald expresses a need for getParameters
> and setParameters to work with the same params and Florent suggests a way
> to solve this by introducing a second argument to the method. There are
> some questions about whether the use case might already be covered by the
> "active" flag, a point first made by Jan-Ivar, but there are problems with
> that IMO and ultimately we ran out of time. So there was some ambiguity if
> this was just bike shedding or if there were legitimately other options,
> but most voices were supporting this and the recorded outcome was to
> "refine the PR". So these discussions continued in follow-ups.
>
> The follow-ups happened during the editors meeting where the PR
>  was refined, approved
> by Jan-Ivar (Mozilla), Bernard (Microsoft) and myself (Google) and merged.
> We went with Florent's suggestion of a second argument which avoided the
> parameter issue that Harald initially raised. My understanding is that
> everyone was happy with it, but I can't speak for other people.
> On Wednesday, January 17, 2024 at 6:02:06 PM UTC+1 vmp...@google.com
> wrote:
>
>> Based on the WG discussion (meeting notes:
>> https://www.w3.org/2023/05/16-webrtc-minutes.html#t04) it didn't seem
>> that there is a very strong consensus that this is a right spot to add an
>> extra parameter. There are also no signals on the RFPs, but the spec PR has
>> landed. How would you assess the vendor support for this change?
>>
>> Thanks,
>> Vlad
>>
>> On Fri, Jan 12, 2024 at 3:10 AM 'Harald Alvestrand' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> This extension has consensus in the WEBRTC WG, and CLs are approved by
>>> the Chrome WebRTC folks.
>>>
>>>
>>> On Fri, Jan 12, 2024 at 8:01 AM 'Philipp Hancke' via blink-dev <
>>> blink-dev@chromium.org> wrote:
>>>
 Contact emails

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

 Explainer

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

 Specification


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

 Summary

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

 Blink component

 Blink>WebRTC>PeerConnection
 

 TAG review

 None, small addition to WebRTC

 TAG review status

 Not applicable

 RisksInteroperability and Compatibility

 None

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

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

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

 Other signals:

 WebView application risks

 Does this intent deprecate or change behavior of existing APIs, such
 that it has potentially high risk for Android WebView-based applications?

 None


 Debuggability

 None

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

 Yes

 Is this feature fully tested by web-platform-tests
 
 ?

 Yes

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

 Flag name on chrome://flags

 None

 Finch feature name

 None

 Non-finch justification

 None

 Requires code in //chrome?

 False

 Tracking bug

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

 Estimated milestones

 Shipping on desktop

 122


 Anticipated spec changes

 None

 Link to entry on the Chrome Platform Status

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

['Vladimir Levin' via blink-dev]

Based on the WG discussion (meeting notes:
https://www.w3.org/2023/05/16-webrtc-minutes.html#t04) it didn't seem that
there is a very strong consensus that this is a right spot to add an extra
parameter. There are also no signals on the RFPs, but the spec PR has
landed. How would you assess the vendor support for this change?

Thanks,
Vlad

On Fri, Jan 12, 2024 at 3:10 AM 'Harald Alvestrand' via blink-dev <
blink-dev@chromium.org> wrote:

> This extension has consensus in the WEBRTC WG, and CLs are approved by the
> Chrome WebRTC folks.
>
>
> On Fri, Jan 12, 2024 at 8:01 AM 'Philipp Hancke' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emails
>>
>> phan...@microsoft.com, ma...@microsoft.com
>>
>> Explainer
>>
>> https://fippo.github.io/webrtc-explainers/rtcrtpsender-setparameters
>>
>> Specification
>>
>>
>> https://w3c.github.io/webrtc-extensions/#rtcrtpsender-setparameters-keyframe
>>
>> Summary
>>
>> Adds an optional second parameter to WebRTC's RTCRtpSender.setParameters
>> call which can be used to ask the associated encoder to generate a key
>> frame.
>>
>> Blink component
>>
>> Blink>WebRTC>PeerConnection
>> 
>>
>> TAG review
>>
>> None, small addition to WebRTC
>>
>> TAG review status
>>
>> Not applicable
>>
>> RisksInteroperability and Compatibility
>>
>> None
>>
>> Gecko: No signal (
>> https://github.com/mozilla/standards-positions/issues/858)
>>
>> WebKit: No signal (
>> https://github.com/WebKit/standards-positions/issues/237)
>>
>> Web developers: Positive Microsoft Teams is quite interested in the
>> feature.
>>
>> Other signals:
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>> None
>>
>>
>> Debuggability
>>
>> None
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, ChromeOS, Android, and Android WebView)?
>>
>> Yes
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>>
>> Yes
>>
>> See WPT added as part of
>> https://chromium-review.googlesource.com/c/chromium/src/+/4643591
>>
>> Flag name on chrome://flags
>>
>> None
>>
>> Finch feature name
>>
>> None
>>
>> Non-finch justification
>>
>> None
>>
>> Requires code in //chrome?
>>
>> False
>>
>> Tracking bug
>>
>> https://bugs.chromium.org/p/chromium/issues/detail?id=1354101
>>
>> Estimated milestones
>>
>> Shipping on desktop
>>
>> 122
>>
>>
>> Anticipated spec changes
>>
>> None
>>
>> Link to entry on the Chrome Platform Status
>>
>> https://chromestatus.com/feature/5161082937409536
>>
>> This intent message was generated by Chrome Platform Status
>>  and then copy-pasted around
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADxkKiJ0%3D-O%2BQoJoXfEWO1KBrLNHWnzTUGxXJSJOpm8BJTQEjw%40mail.gmail.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOqqYVEd14tYEaUdAUCeQGDqEKEJ7EiR1ikENhy%2B5G9sLEu1dA%40mail.gmail.com
> 
> .
>

-- 
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/CADsXd2PqZYvwPqD_koe7ay%2BsJs6bSs%2B_2RDPZRXRzPLKRG4T%2BQ%40mail.gmail.com.

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

['Vladimir Levin' via blink-dev]

On Thu, Jan 11, 2024 at 6:08 PM 'Sahir Vellani' via blink-dev <
blink-dev@chromium.org> wrote:

> Hi all, good news!
>
> Reviving this thread because we have accomplished:
> 1. TAG Review Completion:  Extending the PointerEvent with Unique
> DeviceId Attribute · Issue #880 · w3ctag/design-reviews (github.com)
>  Resolution:
> Satisfied
> 2. WICG Repository for standardization discussions. Link to explainer in
> WICG Repo:  pointer-event-extensions/pointer-event-device-id-explainer.md
> at main · WICG/pointer-event-extensions (github.com)
> 
> 3. A PR against the PointerEvent spec with proposed changes:  Add
> deviceId to PointerEvent spec by sahirv · Pull Request #495 ·
> w3c/pointerevents (github.com)
>  We will be waiting
> for Spec Level 3 to come out before this can be merged; but this provides
> an official starting point for the standardized description of this
> feature. Based on the feedback received, I don't anticipate any major
> changes to the design.
>

For posterity, I was initially unsure why this wasn't an issue on the
w3c/pointerevents, but it does seem like the discussion happened there and
folks agreed to move this in WICG:
https://github.com/w3c/pointerevents/issues/353 \o/


> Reviewers, can we please get another review for shipping this feature?
> On Wednesday, October 18, 2023 at 8:55:43 AM UTC-7 sligh...@chromium.org
> wrote:
>
>> I agree that this needs a spec PR and the explainer should at least
>> migrate to WICG before we agree to ship. Also, can you please link to the
>> TAG review?
>>
>> Best,
>>
>> Alex
>>
>> On Tuesday, October 17, 2023 at 4:16:41 AM UTC-7 Yoav Weiss wrote:
>>
>>> On Tue, Oct 17, 2023 at 12:42 AM Mike Taylor 
>>> wrote:
>>>
 LGTM1
 On 10/15/23 11:07 AM, 'Sahir Vellani' via blink-dev wrote:

 Thanks for the feedback, I wasn't aware they were mandatory. The steps
 have been started, just awaiting feedback from Security and Privacy
 reviewers. I've received LGTMs for all other areas. After our response to
 WebKit's question, they did not have any further follow-up questions. So
 I'm assuming all is well.

 On Wednesday, October 11, 2023 at 4:59:15 AM UTC-7 Daniel Bratell wrote:

> I see that various mandatory steps in chromestatus
> (privacy,security,enterprise,debuggability,testing) seems to be unstarted.
> It is possible they were made mandatory after you create the entry, but it
> would be good if you could get them started now at least.
>
> Also, it's unfortunate that TAG and standards positions requests have
> not resulted in anything, but that is hardly your fault. There were some
> questions in the WebKit request. Is all that ok now?
>
> /Daniel
> On 2023-10-06 20:10, 'Sahir Vellani' via blink-dev wrote:
>
>
>
> On Friday, October 6, 2023 at 9:03:35 AM UTC-7 mike...@chromium.org
> wrote:
>
>
> On 10/4/23 7:43 PM, 'Sahir Vellani' via blink-dev wrote:
>
> Contact emails
> gerc...@microsoft.com, sahir@microsoft.com
>
> Explainer
>
> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/PointerEventDeviceId/explainer.md
>
> Specification
>
> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/PointerEventDeviceId/explainer.md
>
>
>>> Is there a more formal spec for this?
>>> Any support outside of Microsoft that would enable y'all to move this to
>>> the WICG?
>>>
>>>

>
> Summary
>
> As devices with advanced pen input capabilities are becoming
> increasingly prevalent, it is important that the web platform continues to
> evolve to fully support these advanced features in order to unlock rich
> experiences for both end users and developers. One such advancement is the
> ability for a device's digitizer to recognize more than one pen device
> interacting with it simultaneously. This feature is an extension to the
> PointerEvent interface to include a new attribute, deviceId, that
> represents a session-persistent, document isolated, unique identifier that
> a developer can reliably use to identify individual pens interacting with
> the page.
>
>
> Blink component
> Blink>Input
> 
>
> TAG review
> https://github.com/w3ctag/design-reviews/issues/880
>
> TAG review status
> Pending. TAG review has been pending for 2 months.
>
> Risks
>
>
> Interoperability and Compatibility
>
>
> *Gecko*: No signal (
> https://github.com/mozilla/standards-positions/issues/715)
>
> *WebKit*: No signal (
> https://github.com/WebKit/standards-positions/issues/102)
>
> 

Re: [blink-dev] Intent to Ship: Set methods

['Vladimir Levin' via blink-dev]

On Tue, Jan 2, 2024 at 1:51 PM Rezvan Mahdavi Hezaveh 
wrote:

> Contact emailsrez...@chromium.org, s...@chromium.org
>
> ExplainerNone
>
> Specificationhttps://tc39.es/proposal-set-methods
>
> Summary
>
> Set methods are new methods like union and intersection that are added to
> JavaScript's built-in `Set` class.
>
>
> Blink componentBlink>JavaScript>Language
> 
>
> TAG reviewNone
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> No known interop or web compat risk.
>
>
> *Gecko*: Positive (https://bugzilla.mozilla.org/show_bug.cgi?id=1805038)
>
> *WebKit*: Positive (https://bugs.webkit.org/show_bug.cgi?id=254249)
>

It seems like both of these are "Shipped/Shipping", right?


>
> *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
>
> It is debugged as any other static method in JavaScript.
>
>
> 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
> 
> ?It will be tested as soon as test262 tests land:
>
> https://github.com/tc39/test262/pull/3966
>
>
> Flag name on chrome://flags--harmony_set_methods
>
> Finch feature nameNone
>
> Non-finch justificationNone
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/v8/issues/detail?id=13556
>
> Estimated milestones
> Shipping on desktop 122
> DevTrial on desktop 117
> Shipping on Android 122
> DevTrial on Android 117
> 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/6280344932450304
>
> 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/CACJ3t%2BijeWu07rU7LTBKJZ-gxGDR8FbX4FMqXDDq3T4%3D9yjCvQ%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/CADsXd2PfQUmYz58iaFLsGMPXaRo-3by%3DAVidida82VbUACiQbQ%40mail.gmail.com.

Re: [blink-dev] PSA: Changing File System Access API interaction with the back/forward cache

['Vladimir Levin' via blink-dev]

Ah that makes sense! Thank you for explaining!

On Thu, Dec 21, 2023 at 1:57 PM 'Nathan Memmott' via blink-dev <
blink-dev@chromium.org> wrote:

> Sorry, that was poorly worded. We evict "a page in BFCache if *[evicting
> the page in BFCache]* allows another page to take an FSA lock."
>
> For example, a page in BFCache may have a sync access handle open on a
> file. An active page may attempt to open a writable on that same file.
> Previous behavior is to reject with a NoModificationAllowedError. The new
> behavior is to evict the page in BFCache to allow the active page to open
> the writable.
>
> On Thu, Dec 21, 2023, 8:23 AM Vladimir Levin  wrote:
>
>>
>>
>> On Wed, Dec 20, 2023 at 8:17 PM 'Nathan Memmott' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Howdy blink-dev,
>>>
>>> In Chromium M121, we will update how the File System Access (FSA) API
>>> interacts with the back/forward cache (BFCache). This should only affect
>>> the conditions a page can remain in the BFCache. There should be no
>>> behavioral changes to the FSA API.
>>>
>>> A page can hold FSA locks to files via FileSystemWritableFileStream,
>>> FileSystemSyncAccessHandle, and file operations. These FSA locks prevent
>>> incompatible concurrent access to a file (e.g. having both a writable and
>>> access handle open on a file). A page in BFCache can hold FSA locks and
>>> prevent an active (not in BFCache) page from accessing a file. This can be
>>> unexpected behavior to a developer/user.
>>>
>>> The changes made in Chromium M121 address this issue by evicting a page
>>> in BFCache if it allows another page to take an FSA lock. If it doesn't
>>> allow another page to take an FSA lock, then the page can remain in BFCache.
>>>
>>
>> This might be a misunderstanding in terminology on my part, but is this
>> backwards? If the BFCache page allows an active page to acquire a lock,
>> then it's evicted? Or is it then allowed to stay?
>>
>>
>>> This doesn't break any assumptions about concurrent access. An FSA lock
>>> is not given out until incompatible FSA locks have been released.
>>>
>>> This PR for the whatwg/fs spec defines the behavior in more detail:
>>> https://github.com/whatwg/fs/pull/154
>>>
>>> Thanks,
>>> Nathan
>>>
>>> --
>>> 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/CAO4d-SusHj7XEePhBqBkvH24Q50KHF%3DhMNOPpK5wkwpGvkwe4g%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/CAO4d-SuFB_G_H%2Bqdq2OhN6Fc3gR5Npy%3D5unk5EB1bJbzvPRtHg%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/CADsXd2PPjsS7isdROkQRDDiSSfQctSaAHpk%3DWHufACxZCQPhxw%40mail.gmail.com.

Re: [blink-dev] PSA: Changing File System Access API interaction with the back/forward cache

['Vladimir Levin' via blink-dev]

On Wed, Dec 20, 2023 at 8:17 PM 'Nathan Memmott' via blink-dev <
blink-dev@chromium.org> wrote:

> Howdy blink-dev,
>
> In Chromium M121, we will update how the File System Access (FSA) API
> interacts with the back/forward cache (BFCache). This should only affect
> the conditions a page can remain in the BFCache. There should be no
> behavioral changes to the FSA API.
>
> A page can hold FSA locks to files via FileSystemWritableFileStream,
> FileSystemSyncAccessHandle, and file operations. These FSA locks prevent
> incompatible concurrent access to a file (e.g. having both a writable and
> access handle open on a file). A page in BFCache can hold FSA locks and
> prevent an active (not in BFCache) page from accessing a file. This can be
> unexpected behavior to a developer/user.
>
> The changes made in Chromium M121 address this issue by evicting a page in
> BFCache if it allows another page to take an FSA lock. If it doesn't allow
> another page to take an FSA lock, then the page can remain in BFCache.
>

This might be a misunderstanding in terminology on my part, but is this
backwards? If the BFCache page allows an active page to acquire a lock,
then it's evicted? Or is it then allowed to stay?


> This doesn't break any assumptions about concurrent access. An FSA lock is
> not given out until incompatible FSA locks have been released.
>
> This PR for the whatwg/fs spec defines the behavior in more detail:
> https://github.com/whatwg/fs/pull/154
>
> Thanks,
> Nathan
>
> --
> 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/CAO4d-SusHj7XEePhBqBkvH24Q50KHF%3DhMNOPpK5wkwpGvkwe4g%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/CADsXd2P7af9MprWmij%3DCpzYNgmHg8sxnC%3DDYVvPOP%3DLqr6kzHg%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: WebGL drawingBufferStorage

['Vladimir Levin' via blink-dev]

On Mon, Nov 27, 2023 at 4:20 PM 'Christopher Cameron' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emailsccame...@chromium.org
>
> ExplainerNone
>
> Specificationhttps://github.com/KhronosGroup/WebGL/pull/3222
>
> Summary
>
> WebGL allows rendering into textures and renderbuffers of many different
> pixel formats (e.g, 8-bit, floating-point, sRGB-encoded, etc). The drawing
> buffer of WebGL (the buffer that is passed to the compositor) is 8-bit by
> default. This feature allows WebGL to configure the pixel format of this
> drawing buffer. This feature enables WebGL developers to: * avoiding an an
> extra copy convert their rendering to the default drawing buffer pixel
> format * draw content that has a more than 8 bits of precision The latter
> feature unlocks several additional applications * very wide color gamut
> content without loss of precision * medical applications which require >8
> bits of precision * high dynamic range applications (when available)
>
>
> Blink componentBlink>WebGL
> 
>
> TAG reviewNone
>
> TAG review statusNot applicable
>
> Risks
>
>
> Interoperability and Compatibility
>
> None.
>
>
> *Gecko*: Positive Feature authored by Mozilla.
>
> *WebKit*: No signal (
> https://github.com/WebKit/standards-positions/issues/278)
>
> *Web developers*: Positive Positive feedback from several high profile
> web developers - 3D engines that use physically based rendering - image
> editing formats (especially for HDR) - medical imaging applications (which
> require >8 bit precision)
>

This feature sounds like a good addition to the platform. Are there any
(public) links that you point to for developer feedback? I'm mostly curious
to see the discussions


> *Other signals*: This feature's specification was authored by Mozilla.
>
> Ergonomics
>
> None.
>
>
> Activation
>
> No.
>
>
> Security
>
> None.
>
>
> 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
>
> No additional debugging support should be needed.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?Yes
>
> The underlying technology (floating point textures) has almost universal
> support.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?No
>
> This feature is fully tested using WebGL conformance tests, which has been
> checked in.
>
>
> Flag name on chrome://flags
>
> Finch feature nameNone
>
> Requires code in //chrome?False
>
> Availability expectationFeature is available on Web Platform in less than
> a year following launch in Chrome.
>
> Adoption expectationSeveral specific partners have been using this
> feature being chrome://flags' "experimental web platform features", and
> intend to adopt this as soon as it is supported.
>
> 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/5146687245123584
>
> Links to previous Intent discussionsIntent to prototype:
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGnfxj-HFt%3Dk5NBHb5SyNT0ERn6w13S3U8%3DBjV8-4EB4EUoAkw%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/CAGnfxj-0wf-RFAnEaKjT3kJPrMo78QCaEhQZ5EXua4sg2O9qKg%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/CADsXd2PuSVveuPkS3pUKU9tqGEpgYTRA9%2BZDRTnLs4HQaEiivQ%40mail.gmail.com.

Re: [blink-dev] Web-Facing Change PSA: Async Clipboard API: Write well-formed HTML document.

['Vladimir Levin' via blink-dev]

On Mon, Dec 11, 2023 at 6:05 PM 'Anupam Snigdha' via blink-dev <
blink-dev@chromium.org> wrote:

> Contact emails
>
> sni...@microsoft.com, sa...@microsoft.com, est...@chromium.org
>
> Specification
>
>
> https://w3c.github.io/clipboard-apis/#dom-clipboard-write
>
> Design docs
>
>
> https://docs.google.com/document/d/1rTEg2I-hMPXGiLrEMqKJz2Ycu6GRjlM3uvakOe84m8Q/edit?usp=sharing
>
> Summary
>
> The Async clipboard writer API uses sanitizers to strip out content such
> as , , 

Re: [blink-dev] Web-Facing Change PSA: align-content CSS property for blocks

['Vladimir Levin' via blink-dev]

On Mon, Dec 11, 2023 at 10:10 PM 一丝  wrote:

> WebKit is being actively implemented:
> https://github.com/WebKit/WebKit/pull/21522
>
> 以上
> 一丝
>
>
> PhistucK  于2023年12月12日周二 07:50写道：
>
>> > Low risk. This just expands coverage of a CSS property.
>>
>> Well... Not that low, perhaps?
>> I think I used a trick (I suppose) where under some circumstances, I do
>> not want the property (and others that are flexbox-specific) to have any
>> effect, so I just change display to block. Not saying it is a great way
>> to do things, but it does mean that there might be others like me.
>> The risk is usually only due to potential visual glitches for the most
>> part, I suppose, but it might be more than that (things being
>> hidden/unreachable).
>>
>> ☆*PhistucK*
>>
>>
>> On Mon, Dec 11, 2023 at 11:07 PM TAMURA, Kent  wrote:
>>
>>> Contact emailstk...@chromium.org, ikilpatr...@chromium.org
>>>
>>> Specificationhttps://drafts.csswg.org/css-align/#distribution-block
>>>
>>> Summary
>>>
>>> `align-content` CSS property works for block containers and table cells.
>>> The property worked only for flex containers and grid containers. It
>>> supports block containers and table cells, that is to say `display: block`,
>>> `display: list-item`, `display: table-cell`, etc.
>>>
>>>
>>> Blink componentBlink>Layout
>>> 
>>>
>>> Search tagscss ,
>>> align-content 
>>>
>>> TAG reviewNone; API surface is not changed.
>>>
>>> TAG review statusNot applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> Low risk. This just expands coverage of a CSS property.
>>>
>>>
>>> *Gecko*: No signal
>>>
>>
It's worthwhile to file a request for position here as well to ensure there
are no concerns -- unless the position is already expressed elsewhere


>
>>> *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
>>>
>>> https://wpt.fyi/results/css/css-align/blocks
>>> https://wpt.fyi/results/css/css-align/multicol
>>>
>>>
>>> Flag name on chrome://flagsAlignContentForBlocks
>>>
>>> Finch feature nameAlignContentForBlocks
>>>
>>> Requires code in //chrome?False
>>>
>>> Tracking bug
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1500511
>>>
>>> Estimated milestones
>>> Shipping on desktop 122
>>> DevTrial on desktop 121
>>> Shipping on Android 122
>>> DevTrial on Android 121
>>> 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/5159040328138752
>>>
>>> This intent message was generated by Chrome Platform Status
>>> .
>>>
>>> --
>>> TAMURA Kent
>>> Software Engineer, Google
>>>
>>>
>>> --
>>> 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/CAGH7WqFRawiS9g5UpYs4Nkh74MqQNdB4F2AMOdRJyC4Z-f2PUQ%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/CABc02_%2BKngSYY2afeLa5RHU4XEcmn_mmj3hx_T0AWADg8BHH_Q%40mail.gmail.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the Google Groups
> 

Re: [blink-dev] Intent to Prototype: NavigateEvent sourceElement

['Vladimir Levin' via blink-dev]

On Mon, Sep 25, 2023 at 3:41 PM Nate Chapin  wrote:

> Contact emailsjap...@chromium.org, dome...@chromium.org
>
> Explainer
> https://github.com/WICG/navigation-api/commit/85edaf1d4d42355b020807cd56f6a22784978c3d
>
> SpecificationNone
>
> Summary
>
> When a navigation is initiated by an Element (i.e., a link click or a form
> submission), the sourceElement property on the NavigateEvent will be the
> initiating element.
>
>
> Blink componentBlink>History
> 
>
> Motivation
>
> This was requested by web developers. It provides an easy way to
> disambiguate which of several possible elements initiated a navigation.
>
>
> Initial public proposalhttps://github.com/WICG/navigation-api/issues/225
>
> TAG review
>

FWIW, TAG review is here:
https://github.com/w3ctag/design-reviews/issues/867


>
>
> TAG review statusPending
>
> Risks
>
>
> Interoperability and Compatibility
>
> None
>
>
> *Gecko*: No signal
>
> *WebKit*: No signal
>
> *Web developers*: Strongly positive (
> https://github.com/WICG/navigation-api/issues/225)
>
> *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
>
> Flag name on chrome://flagsNone
>
> Finch feature nameNone
>
> Non-finch justificationNone
>
> Requires code in //chrome?False
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1483000
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5134353390895104
>
> 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/CACf%3D2LK%3DHeSj%2B5eQt1O23-TiO6Mai%2Bhdv-E%3DzMguriouYi6gVw%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/CADsXd2OqwC5AOHTqZXR6txmcHerfSDkY-z8RvDEJ8Df%2BvDQyyQ%40mail.gmail.com.

Re: [blink-dev] Intent to Prototype and Ship: contain-intrinsic-size: auto none support

['Vladimir Levin' via blink-dev]

On Mon, Jun 26, 2023 at 12:44 PM Vladimir Levin  wrote:

>
> On Mon, Jun 26, 2023 at 12:16 PM Yoav Weiss 
> wrote:
>
>>
>>
>> On Mon, Jun 26, 2023 at 5:35 PM Vladimir Levin  wrote:
>>
>>>
>>>
>>> On Fri, Jun 16, 2023 at 1:12 PM Vladimir Levin 
>>> wrote:
>>>
>>>> Thank you for your feedback. My responses are inline below
>>>>
>>>> On Wed, Jun 14, 2023 at 12:24 AM Yoav Weiss 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Fri, Jun 9, 2023 at 10:19 PM 'Vladimir Levin' via blink-dev <
>>>>> blink-dev@chromium.org> wrote:
>>>>>
>>>>>> Contact emailsvmp...@chromium.org
>>>>>>
>>>>>> SpecificationNone
>>>>>>
>>>>>> Summary
>>>>>>
>>>>>> This feature extends the existing contain-intrinsic-size syntax: none
>>>>>> |  | auto &&  to also include auto && none: none | 
>>>>>> 
>>>>>> | auto &&  | auto && none The reason for this change is the CSSWG
>>>>>> resolution (
>>>>>> https://github.com/w3c/csswg-drafts/issues/8407#issuecomment-1440466558)
>>>>>> to add an interaction between content-visibility: auto and
>>>>>> contain-intrinsic-size. Specifically, that the former adds an "auto"
>>>>>> keyword to the latter. For this to work, the resolution includes a note 
>>>>>> to
>>>>>> extend contain-intrinsic-size syntax for "auto" to work with all existing
>>>>>> keywords, including "none".
>>>>>>
>>>>>>
>>>>>> Blink componentBlink>CSS
>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS>
>>>>>>
>>>>>> TAG reviewNone
>>>>>>
>>>>>> TAG review statusNot applicable
>>>>>>
>>>>>> Risks
>>>>>>
>>>>>>
>>>>>> Interoperability and Compatibility
>>>>>>
>>>>>> There is a risk of interoperability since the new syntax would
>>>>>> previously be considered invalid, and result in a default behavior
>>>>>> (equivalent to contain-intrinsic-size: none). Sites currently specifying
>>>>>> contain-intrinsic-size: auto none would have their behavior change on
>>>>>> Chromium after this feature launches.
>>>>>>
>>>>>>
>>>>>> I estimate this risk to be low.
>>>>>>
>>>>>
>>>>> Would you be able to confirm that estimate e.g. with an HTTP archive
>>>>> search?
>>>>>
>>>>
>>>> I'm in the process of figuring out how to do this, and will get back to
>>>> you with the results when I have them. My estimate stems from the fact that
>>>> currently "contain-intrinsic-size: auto none" is considered an invalid
>>>> syntax, making it unlikely to be used as a value.
>>>>
>>>
>>> Based on my http archive queries that use regular expression to match
>>> particular values of contain-intrinsic-[a-z-]* (size, width, height,
>>> block-size, inline-size), out of all of the contain-intrinsic-* values, 
>>> *about
>>> half of them (50%) have an 'auto' keyword *that follows the semicolon
>>> and possibly whitespace. *However, 0 of those have "auto[ ]*none" in
>>> them*.
>>>
>>> As a disclaimer, the total amount of contain-intrinsic-* pages I got
>>> using these queries is substantially smaller than the use counter data
>>> would indicate. I presume this is due to limitations such as case
>>> sensitivity, script constructing these values, etc, but I'm not sure.
>>>
>>> This seems to confirm my estimate of low risk in enabling this by
>>> default. Let me know if you agree, or whether you'd like me to do more
>>> research.
>>>
>>
>> Thanks for confirming that!!
>>
>>
>>>
>>> Thanks in advance,
>>> vmpstr
>>>
>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> *Gecko*: No signal This change was discussed in CSSWG and there were
>>>>>> no objections to the resolutions
>>>>>

Re: [blink-dev] Intent to Prototype and Ship: contain-intrinsic-size: auto none support

['Vladimir Levin' via blink-dev]

On Mon, Jun 26, 2023 at 12:16 PM Yoav Weiss  wrote:

>
>
> On Mon, Jun 26, 2023 at 5:35 PM Vladimir Levin  wrote:
>
>>
>>
>> On Fri, Jun 16, 2023 at 1:12 PM Vladimir Levin  wrote:
>>
>>> Thank you for your feedback. My responses are inline below
>>>
>>> On Wed, Jun 14, 2023 at 12:24 AM Yoav Weiss 
>>> wrote:
>>>
>>>>
>>>>
>>>> On Fri, Jun 9, 2023 at 10:19 PM 'Vladimir Levin' via blink-dev <
>>>> blink-dev@chromium.org> wrote:
>>>>
>>>>> Contact emailsvmp...@chromium.org
>>>>>
>>>>> SpecificationNone
>>>>>
>>>>> Summary
>>>>>
>>>>> This feature extends the existing contain-intrinsic-size syntax: none
>>>>> |  | auto &&  to also include auto && none: none | 
>>>>> 
>>>>> | auto &&  | auto && none The reason for this change is the CSSWG
>>>>> resolution (
>>>>> https://github.com/w3c/csswg-drafts/issues/8407#issuecomment-1440466558)
>>>>> to add an interaction between content-visibility: auto and
>>>>> contain-intrinsic-size. Specifically, that the former adds an "auto"
>>>>> keyword to the latter. For this to work, the resolution includes a note to
>>>>> extend contain-intrinsic-size syntax for "auto" to work with all existing
>>>>> keywords, including "none".
>>>>>
>>>>>
>>>>> Blink componentBlink>CSS
>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS>
>>>>>
>>>>> TAG reviewNone
>>>>>
>>>>> TAG review statusNot applicable
>>>>>
>>>>> Risks
>>>>>
>>>>>
>>>>> Interoperability and Compatibility
>>>>>
>>>>> There is a risk of interoperability since the new syntax would
>>>>> previously be considered invalid, and result in a default behavior
>>>>> (equivalent to contain-intrinsic-size: none). Sites currently specifying
>>>>> contain-intrinsic-size: auto none would have their behavior change on
>>>>> Chromium after this feature launches.
>>>>>
>>>>>
>>>>> I estimate this risk to be low.
>>>>>
>>>>
>>>> Would you be able to confirm that estimate e.g. with an HTTP archive
>>>> search?
>>>>
>>>
>>> I'm in the process of figuring out how to do this, and will get back to
>>> you with the results when I have them. My estimate stems from the fact that
>>> currently "contain-intrinsic-size: auto none" is considered an invalid
>>> syntax, making it unlikely to be used as a value.
>>>
>>
>> Based on my http archive queries that use regular expression to match
>> particular values of contain-intrinsic-[a-z-]* (size, width, height,
>> block-size, inline-size), out of all of the contain-intrinsic-* values, 
>> *about
>> half of them (50%) have an 'auto' keyword *that follows the semicolon
>> and possibly whitespace. *However, 0 of those have "auto[ ]*none" in
>> them*.
>>
>> As a disclaimer, the total amount of contain-intrinsic-* pages I got
>> using these queries is substantially smaller than the use counter data
>> would indicate. I presume this is due to limitations such as case
>> sensitivity, script constructing these values, etc, but I'm not sure.
>>
>> This seems to confirm my estimate of low risk in enabling this by
>> default. Let me know if you agree, or whether you'd like me to do more
>> research.
>>
>
> Thanks for confirming that!!
>
>
>>
>> Thanks in advance,
>> vmpstr
>>
>>
>>>
>>>>
>>>>
>>>>>
>>>>> *Gecko*: No signal This change was discussed in CSSWG and there were
>>>>> no objections to the resolutions
>>>>>
>>>>> *WebKit*: No signal This change was discussed in CSSWG and there were
>>>>> no objections to the resolutions
>>>>>
>>>>
>>>> Can you please file signals? I don't believe a CSSWG counts as a
>>>> positive signal. Also, I don't believe I saw a comment from any WebKit
>>>> person on the minutes.
>>>> A signal request would let them know this is being worked on in
>>>> Chromium.
>>>>

Re: [blink-dev] Intent to Prototype and Ship: contain-intrinsic-size: auto none support

['Vladimir Levin' via blink-dev]

On Fri, Jun 16, 2023 at 1:12 PM Vladimir Levin  wrote:

> Thank you for your feedback. My responses are inline below
>
> On Wed, Jun 14, 2023 at 12:24 AM Yoav Weiss 
> wrote:
>
>>
>>
>> On Fri, Jun 9, 2023 at 10:19 PM 'Vladimir Levin' via blink-dev <
>> blink-dev@chromium.org> wrote:
>>
>>> Contact emailsvmp...@chromium.org
>>>
>>> SpecificationNone
>>>
>>> Summary
>>>
>>> This feature extends the existing contain-intrinsic-size syntax: none |
>>>  | auto &&  to also include auto && none: none |  |
>>> auto &&  | auto && none The reason for this change is the CSSWG
>>> resolution (
>>> https://github.com/w3c/csswg-drafts/issues/8407#issuecomment-1440466558)
>>> to add an interaction between content-visibility: auto and
>>> contain-intrinsic-size. Specifically, that the former adds an "auto"
>>> keyword to the latter. For this to work, the resolution includes a note to
>>> extend contain-intrinsic-size syntax for "auto" to work with all existing
>>> keywords, including "none".
>>>
>>>
>>> Blink componentBlink>CSS
>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS>
>>>
>>> TAG reviewNone
>>>
>>> TAG review statusNot applicable
>>>
>>> Risks
>>>
>>>
>>> Interoperability and Compatibility
>>>
>>> There is a risk of interoperability since the new syntax would
>>> previously be considered invalid, and result in a default behavior
>>> (equivalent to contain-intrinsic-size: none). Sites currently specifying
>>> contain-intrinsic-size: auto none would have their behavior change on
>>> Chromium after this feature launches.
>>>
>>>
>>> I estimate this risk to be low.
>>>
>>
>> Would you be able to confirm that estimate e.g. with an HTTP archive
>> search?
>>
>
> I'm in the process of figuring out how to do this, and will get back to
> you with the results when I have them. My estimate stems from the fact that
> currently "contain-intrinsic-size: auto none" is considered an invalid
> syntax, making it unlikely to be used as a value.
>

Based on my http archive queries that use regular expression to match
particular values of contain-intrinsic-[a-z-]* (size, width, height,
block-size, inline-size), out of all of the contain-intrinsic-* values, *about
half of them (50%) have an 'auto' keyword *that follows the semicolon and
possibly whitespace. *However, 0 of those have "auto[ ]*none" in them*.

As a disclaimer, the total amount of contain-intrinsic-* pages I got using
these queries is substantially smaller than the use counter data would
indicate. I presume this is due to limitations such as case sensitivity,
script constructing these values, etc, but I'm not sure.

This seems to confirm my estimate of low risk in enabling this by default.
Let me know if you agree, or whether you'd like me to do more research.

Thanks in advance,
vmpstr


>
>>
>>
>>>
>>> *Gecko*: No signal This change was discussed in CSSWG and there were no
>>> objections to the resolutions
>>>
>>> *WebKit*: No signal This change was discussed in CSSWG and there were
>>> no objections to the resolutions
>>>
>>
>> Can you please file signals? I don't believe a CSSWG counts as a positive
>> signal. Also, I don't believe I saw a comment from any WebKit person on the
>> minutes.
>> A signal request would let them know this is being worked on in Chromium.
>>
>
> I have filed the following requests for positions:
> Mozilla: https://github.com/mozilla/standards-positions/issues/827
> WebKit: https://github.com/WebKit/standards-positions/issues/205
>
> I've updated the chrome status entry page with this information.
>
> Thanks,
> vmpstr
>
>
>
>>
>>>
>>> *Web developers*: No signals
>>>
>>> *Other signals*:
>>>
>>> Ergonomics
>>>
>>> None. This is an improvement which will allow future work to improve
>>> ergonomics of content-visibility.
>>>
>>>
>>> Activation
>>>
>>> None.
>>>
>>>
>>> Security
>>>
>>> None.
>>>
>>>
>>> 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
>

Re: [blink-dev] Intent to Prototype and Ship: contain-intrinsic-size: auto none support

['Vladimir Levin' via blink-dev]

Thank you for your feedback. My responses are inline below

On Wed, Jun 14, 2023 at 12:24 AM Yoav Weiss  wrote:

>
>
> On Fri, Jun 9, 2023 at 10:19 PM 'Vladimir Levin' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emailsvmp...@chromium.org
>>
>> SpecificationNone
>>
>> Summary
>>
>> This feature extends the existing contain-intrinsic-size syntax: none |
>>  | auto &&  to also include auto && none: none |  |
>> auto &&  | auto && none The reason for this change is the CSSWG
>> resolution (
>> https://github.com/w3c/csswg-drafts/issues/8407#issuecomment-1440466558)
>> to add an interaction between content-visibility: auto and
>> contain-intrinsic-size. Specifically, that the former adds an "auto"
>> keyword to the latter. For this to work, the resolution includes a note to
>> extend contain-intrinsic-size syntax for "auto" to work with all existing
>> keywords, including "none".
>>
>>
>> Blink componentBlink>CSS
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ECSS>
>>
>> TAG reviewNone
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>> There is a risk of interoperability since the new syntax would previously
>> be considered invalid, and result in a default behavior (equivalent to
>> contain-intrinsic-size: none). Sites currently specifying
>> contain-intrinsic-size: auto none would have their behavior change on
>> Chromium after this feature launches.
>>
>>
>> I estimate this risk to be low.
>>
>
> Would you be able to confirm that estimate e.g. with an HTTP archive
> search?
>

I'm in the process of figuring out how to do this, and will get back to you
with the results when I have them. My estimate stems from the fact that
currently "contain-intrinsic-size: auto none" is considered an invalid
syntax, making it unlikely to be used as a value.


>
>
>>
>> *Gecko*: No signal This change was discussed in CSSWG and there were no
>> objections to the resolutions
>>
>> *WebKit*: No signal This change was discussed in CSSWG and there were no
>> objections to the resolutions
>>
>
> Can you please file signals? I don't believe a CSSWG counts as a positive
> signal. Also, I don't believe I saw a comment from any WebKit person on the
> minutes.
> A signal request would let them know this is being worked on in Chromium.
>

I have filed the following requests for positions:
Mozilla: https://github.com/mozilla/standards-positions/issues/827
WebKit: https://github.com/WebKit/standards-positions/issues/205

I've updated the chrome status entry page with this information.

Thanks,
vmpstr



>
>>
>> *Web developers*: No signals
>>
>> *Other signals*:
>>
>> Ergonomics
>>
>> None. This is an improvement which will allow future work to improve
>> ergonomics of content-visibility.
>>
>>
>> Activation
>>
>> None.
>>
>>
>> Security
>>
>> None.
>>
>>
>> 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
>>
>> This feature is debuggable in the same way as other CSS features.
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?Yes
>>
>> Is this feature fully tested by web-platform-tests
>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>> ?Yes
>>
>> Flag nameCSSContainIntrinsicSizeAutoNone
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1453733
>>
>> Estimated milestones
>>
>> M116
>>
>> 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/6203168806928384
>>
>> Links to previous Intent discussions
>&g

[blink-dev] Intent to Prototype and Ship: contain-intrinsic-size: auto none support

['Vladimir Levin' via blink-dev]

Contact emailsvmp...@chromium.org

SpecificationNone

Summary

This feature extends the existing contain-intrinsic-size syntax: none |
 | auto &&  to also include auto && none: none |  |
auto &&  | auto && none The reason for this change is the CSSWG
resolution (
https://github.com/w3c/csswg-drafts/issues/8407#issuecomment-1440466558) to
add an interaction between content-visibility: auto and
contain-intrinsic-size. Specifically, that the former adds an "auto"
keyword to the latter. For this to work, the resolution includes a note to
extend contain-intrinsic-size syntax for "auto" to work with all existing
keywords, including "none".


Blink componentBlink>CSS


TAG reviewNone

TAG review statusNot applicable

Risks


Interoperability and Compatibility

There is a risk of interoperability since the new syntax would previously
be considered invalid, and result in a default behavior (equivalent to
contain-intrinsic-size: none). Sites currently specifying
contain-intrinsic-size: auto none would have their behavior change on
Chromium after this feature launches.


I estimate this risk to be low.


*Gecko*: No signal This change was discussed in CSSWG and there were no
objections to the resolutions

*WebKit*: No signal This change was discussed in CSSWG and there were no
objections to the resolutions

*Web developers*: No signals

*Other signals*:

Ergonomics

None. This is an improvement which will allow future work to improve
ergonomics of content-visibility.


Activation

None.


Security

None.


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

This feature is debuggable in the same way as other CSS features.


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

Is this feature fully tested by web-platform-tests

?Yes

Flag nameCSSContainIntrinsicSizeAutoNone

Requires code in //chrome?False

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

Estimated milestones

M116

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

Links to previous Intent discussions

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

Re: [blink-dev] Intent to Ship: ContentVisibilityAutoStateChanged event

['Vladimir Levin' via blink-dev]

Hi all,

CSSWG resolved on renaming this event to be in the present tense:
ContentVisibilityAutoStateChangeEvent instead of
ContentVisibilityAutoStateChangedEvent
(https://github.com/w3c/csswg-drafts/issues/7603#issuecomment-1309133575)

This is currently in the Beta channel (m108). According to
https://chromestatus.com/metrics/feature/popularity#ContentVisibilityAutoStateChangedHandlerRegistered
there's 0.0191% usage of this (event handler being registered), although
the timeline view doesn't show any data.

I would like to rename the event, and attempt to merge this to beta. I will
also reach out to partners that we worked with for this event to ensure
they are aware of this change.

Please let me know if there are concerns with this plan.

Thanks,
Vlad

On Wed, Aug 31, 2022 at 11:39 AM Philip Jägenstedt 
wrote:

> LGTM3 on the assumption that the spec discussion will be sorted out and
> spec fixed by the time this rolls out to stable.
>
> On Wed, Aug 31, 2022 at 3:47 PM Yoav Weiss  wrote:
>
>> LGTM2 conditional on driving the discussion on the Mozilla position
>> thread to completion and making sure the spec text properly reflects it.
>>
>> On Thu, Aug 11, 2022 at 12:48 AM slightlyoff via Chromestatus <
>> admin+slightly...@cr-status.appspotmail.com> wrote:
>>
>>> LGTM1
>>>
>>> --
>>> 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/5788c005e5ead850%40google.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/CAL5BFfU%3DV6M7KXYdwwWm_RFyzH7APA8pymm3_eno3ep7SCNgCg%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/CAARdPYfUH%2B2XfktP%2BzOPyL5Q6CMP82Q4dTPG6BqHuDWbTTkHxQ%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/CADsXd2NjwAVNVGdtoyJ2q0hru0acBnfa2T8POaHK2pK1gwgOUA%40mail.gmail.com.