[blink-dev] Re: Intent to Prototype: Confirmation of Action API

2022-01-28 Thread 'Sara Tang' via blink-dev 
+Daniel Libby

From: Sara Tang
Sent: Friday, January 28, 2022 4:26 PM
To: blink-dev@chromium.org 
Subject: Intent to Prototype: Confirmation of Action API

Contact emails
sart...@microsoft.com

Explainer
https://github.com/WICG/aom/blob/gh-pages/notification-api.md

Specification


Summary

This effort aims to create a JavaScript API so that developers can better 
notify AT users of actions/changes to a webpage not necessarily tied to UI 
elements.


Blink component
Blink>Accessibility

Motivation

Currently the only mechanism available today that communicates content changes 
in a web app down to the accessibility layer is via ARIA live regions. One 
major limitation to ARIA live regions is that they assume the change to a 
webpage is tied to a DOM element. This leads to content authors employing 
various inefficient or inconsistent tricks and hacks to notify of changes that 
are not associated with the DOM. We propose a separate notification API to 
address these scenarios, called Confirmation of Action.


Initial public proposal
https://github.com/WICG/aom/blob/gh-pages/notification-api.md

TAG review


TAG review status
Pending

Risks


Interoperability and Compatibility


Gecko: No signal

WebKit: No signal

Web developers: Positive (https://github.com/w3c/aria/issues/832)

Other signals:


Debuggability

TBD


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

Flag name
--enable-blink-features=ConfirmationOfAction

Requires code in //chrome?
False

Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1291098

Estimated milestones

No milestones specified


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

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/CH2PR00MB06809C5589E8FD6848CF5E09F2239%40CH2PR00MB0680.namprd00.prod.outlook.com.

[blink-dev] Intent to Prototype: Confirmation of Action API

2022-01-28 Thread 'Sara Tang' via blink-dev 
Contact emails
sart...@microsoft.com

Explainer
https://github.com/WICG/aom/blob/gh-pages/notification-api.md

Specification


Summary

This effort aims to create a JavaScript API so that developers can better 
notify AT users of actions/changes to a webpage not necessarily tied to UI 
elements.


Blink component
Blink>Accessibility

Motivation

Currently the only mechanism available today that communicates content changes 
in a web app down to the accessibility layer is via ARIA live regions. One 
major limitation to ARIA live regions is that they assume the change to a 
webpage is tied to a DOM element. This leads to content authors employing 
various inefficient or inconsistent tricks and hacks to notify of changes that 
are not associated with the DOM. We propose a separate notification API to 
address these scenarios, called Confirmation of Action.


Initial public proposal
https://github.com/WICG/aom/blob/gh-pages/notification-api.md

TAG review


TAG review status
Pending

Risks


Interoperability and Compatibility


Gecko: No signal

WebKit: No signal

Web developers: Positive (https://github.com/w3c/aria/issues/832)

Other signals:


Debuggability

TBD


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

Flag name
--enable-blink-features=ConfirmationOfAction

Requires code in //chrome?
False

Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1291098

Estimated milestones

No milestones specified


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

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/CH2PR00MB0680B14C1978202FF59CF7D3F2239%40CH2PR00MB0680.namprd00.prod.outlook.com.

Re: [EXTERNAL] Re: [blink-dev] Intent to implement: Fluent Scrollbars.

2022-01-28 Thread Chris Harrelson 
Re Linux: I'm hoping we can just use the same code on Linux so that we have
overlay scrollbars everywhere. Rahul, would that work code-wise?

On Fri, Jan 28, 2022 at 3:40 PM Ian Kilpatrick 
wrote:

> Exciting!
>
> Adding onto Rahul's answer here a little - overlay scrollbars (or
> scrollbars which take to zero space) already exist on other platforms (e.g.
> they are the default on OSX). It won't/shouldn't be a web compat concern as
> most websites handle this already.
>
> An interesting side effect of this will likely be that we'll see more
> sites (who are built after this change goes in) assume that scrollbars are
> always zero width (as this is now the default on all platforms except
> linux?) and as a result more content going forward being broken for those
> users who opt-out.
> (To be clear there isn't much we can do about this - but an interesting
> side effect).
>
> Ian
>
> On Fri, Jan 28, 2022 at 2:51 PM 'Rahul Arakeri' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Hi Mike,
>>
>>
>>
>> Sure, I’ve created a chromestatus entry here:
>> https://chromestatus.com/feature/5693137379917824
>>
>> And yes, this proposed change is expected to have an impact on the page’s
>> layout. In it’s default state, the scrollbars will be in “minimal mode”
>> (aka overlay scrollbars). These will *not* take up any layout space
>> (whereas, today in Chromium, the default scrollbars take up 17px AFAIK).
>>
>> The users will however still have an option to “Always show scrollbars”
>> via an OS setting. These *will* take up layout space (similar to what
>> Chromium scrollbars do today).
>>
>>
>>
>> Thanks,
>>
>> Rahul
>>
>>
>>
>> *From:* Mike Taylor 
>> *Sent:* Friday, January 28, 2022 12:20 PM
>> *To:* Rahul Arakeri 
>> *Cc:* blink-dev@chromium.org; Robert Flack ;
>> wangxianzhu ; p...@chromium.org;
>> input-...@chromium.org; Yaroslav Shalivskyy ;
>> Olga Gerchikov ; Sahir Vellani <
>> sahir.vell...@microsoft.com>; Ben Mathwig > >
>> *Subject:* [EXTERNAL] Re: [blink-dev] Intent to implement: Fluent
>> Scrollbars.
>>
>>
>>
>> Hi Rahul,
>>
>>
>>
>> Would you mind creating a chromestatus entry for this intent? (See "Step
>> 0" at http://dev.chromium.org/blink/launching-features
>> 
>> for a link).
>>
>>
>>
>> Also, out of curiosity (because I don't know much about scrollbars) -
>> will this proposed change have an impact on a page's layout?
>>
>>
>>
>> thanks,
>> Mike
>>
>>
>>
>> On 1/28/22 2:50 PM, 'Rahul Arakeri' via blink-dev wrote:
>>
>> *Intent to implement: Fluent Scrollbars.*
>>
>>
>>
>> *Contact emails*
>>
>> Rahul Arakeri: arak...@microsoft.com
>>
>> Yaroslav Shalivskyy: yshalivs...@microsoft.com
>>
>> Sahir Vellani: sahir.vell...@microsoft.com
>>
>> Olga Gerchikov: gerch...@microsoft.com
>>
>> Ben Mathwig: benjamin.math...@microsoft.com
>>
>>
>>
>> *Visual Spec*
>>
>>
>> https://docs.google.com/document/d/1EpJnWAcPCxBQo6zPGR1Tg1NACiIJ-6dk7cYyK1DhBWw/edit
>> 
>>
>>
>>
>> *Summary*
>>
>> This proposal is to modernize the Chromium scrollbars (both overlay and
>> non-overlay) to fit the Windows 11 Fluent design language. As a part of
>> this effort, we are proposing to update the visual appearance along with
>> some changes to how users interact with overlay scrollbars.
>>
>>
>>
>> *Motivation*
>>
>> As the rest of Windows has been embracing WinUI and native Fluent
>> controls, certain non-XAML apps like Chromium-based browsers still use the
>> traditional (Win32 looking) scrollbars. As such, we believe that the visual
>> appearance of scrollbars could use an update in the interest of maintaining
>> homogeneity with the rest of Windows.
>>
>> In a nutshell, we’re proposing that the default scrollbars should act
>> more like overlay scrollbars, be thinner, have insets and rounded edges.
>> Users will still have an option to select non overlay scrollbars via the
>> "Always show scrollbars" OS setting. Non overlay scrollbars will also be
>> restyled to match Windows theme. For details on scrollbar styling and state
>> transitions, please see the visual spec linked above.
>>
>> Also, please note that since some HTML controls (like  and
>> ) depend on the ScrollbarTheme

Re: [EXTERNAL] Re: [blink-dev] Intent to implement: Fluent Scrollbars.

2022-01-28 Thread Ian Kilpatrick 
Exciting!

Adding onto Rahul's answer here a little - overlay scrollbars (or
scrollbars which take to zero space) already exist on other platforms (e.g.
they are the default on OSX). It won't/shouldn't be a web compat concern as
most websites handle this already.

An interesting side effect of this will likely be that we'll see more sites
(who are built after this change goes in) assume that scrollbars are always
zero width (as this is now the default on all platforms except linux?) and
as a result more content going forward being broken for those users who
opt-out.
(To be clear there isn't much we can do about this - but an interesting
side effect).

Ian

On Fri, Jan 28, 2022 at 2:51 PM 'Rahul Arakeri' via blink-dev <
blink-dev@chromium.org> wrote:

> Hi Mike,
>
>
>
> Sure, I’ve created a chromestatus entry here:
> https://chromestatus.com/feature/5693137379917824
>
> And yes, this proposed change is expected to have an impact on the page’s
> layout. In it’s default state, the scrollbars will be in “minimal mode”
> (aka overlay scrollbars). These will *not* take up any layout space
> (whereas, today in Chromium, the default scrollbars take up 17px AFAIK).
>
> The users will however still have an option to “Always show scrollbars”
> via an OS setting. These *will* take up layout space (similar to what
> Chromium scrollbars do today).
>
>
>
> Thanks,
>
> Rahul
>
>
>
> *From:* Mike Taylor 
> *Sent:* Friday, January 28, 2022 12:20 PM
> *To:* Rahul Arakeri 
> *Cc:* blink-dev@chromium.org; Robert Flack ;
> wangxianzhu ; p...@chromium.org;
> input-...@chromium.org; Yaroslav Shalivskyy ;
> Olga Gerchikov ; Sahir Vellani <
> sahir.vell...@microsoft.com>; Ben Mathwig 
> *Subject:* [EXTERNAL] Re: [blink-dev] Intent to implement: Fluent
> Scrollbars.
>
>
>
> Hi Rahul,
>
>
>
> Would you mind creating a chromestatus entry for this intent? (See "Step
> 0" at http://dev.chromium.org/blink/launching-features
> 
> for a link).
>
>
>
> Also, out of curiosity (because I don't know much about scrollbars) - will
> this proposed change have an impact on a page's layout?
>
>
>
> thanks,
> Mike
>
>
>
> On 1/28/22 2:50 PM, 'Rahul Arakeri' via blink-dev wrote:
>
> *Intent to implement: Fluent Scrollbars.*
>
>
>
> *Contact emails*
>
> Rahul Arakeri: arak...@microsoft.com
>
> Yaroslav Shalivskyy: yshalivs...@microsoft.com
>
> Sahir Vellani: sahir.vell...@microsoft.com
>
> Olga Gerchikov: gerch...@microsoft.com
>
> Ben Mathwig: benjamin.math...@microsoft.com
>
>
>
> *Visual Spec*
>
>
> https://docs.google.com/document/d/1EpJnWAcPCxBQo6zPGR1Tg1NACiIJ-6dk7cYyK1DhBWw/edit
> 
>
>
>
> *Summary*
>
> This proposal is to modernize the Chromium scrollbars (both overlay and
> non-overlay) to fit the Windows 11 Fluent design language. As a part of
> this effort, we are proposing to update the visual appearance along with
> some changes to how users interact with overlay scrollbars.
>
>
>
> *Motivation*
>
> As the rest of Windows has been embracing WinUI and native Fluent
> controls, certain non-XAML apps like Chromium-based browsers still use the
> traditional (Win32 looking) scrollbars. As such, we believe that the visual
> appearance of scrollbars could use an update in the interest of maintaining
> homogeneity with the rest of Windows.
>
> In a nutshell, we’re proposing that the default scrollbars should act more
> like overlay scrollbars, be thinner, have insets and rounded edges. Users
> will still have an option to select non overlay scrollbars via the "Always
> show scrollbars" OS setting. Non overlay scrollbars will also be restyled
> to match Windows theme. For details on scrollbar styling and state
> transitions, please see the visual spec linked above.
>
> Also, please note that since some HTML controls (like  and
> ) depend on the ScrollbarThemes(s) that are being refreshed, they
> too will also get the new scrollbars.
>
>
>
> *Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?*
>
> No, this is aimed at Windows for now. However, it can be made available on
> Linux too.
>
>
>
> *Ongoing technical constraints*
>
> No

RE: [EXTERNAL] Re: [blink-dev] Intent to implement: Fluent Scrollbars.

2022-01-28 Thread 'Rahul Arakeri' via blink-dev 
Hi Mike,

Sure, I’ve created a chromestatus entry here: 
https://chromestatus.com/feature/5693137379917824
And yes, this proposed change is expected to have an impact on the page’s 
layout. In it’s default state, the scrollbars will be in “minimal mode” (aka 
overlay scrollbars). These will not take up any layout space (whereas, today in 
Chromium, the default scrollbars take up 17px AFAIK).
The users will however still have an option to “Always show scrollbars” via an 
OS setting. These will take up layout space (similar to what Chromium 
scrollbars do today).

Thanks,
Rahul

From: Mike Taylor 
Sent: Friday, January 28, 2022 12:20 PM
To: Rahul Arakeri 
Cc: blink-dev@chromium.org; Robert Flack ; wangxianzhu 
; p...@chromium.org; input-...@chromium.org; Yaroslav 
Shalivskyy ; Olga Gerchikov 
; Sahir Vellani ; Ben 
Mathwig 
Subject: [EXTERNAL] Re: [blink-dev] Intent to implement: Fluent Scrollbars.

Hi Rahul,

Would you mind creating a chromestatus entry for this intent? (See "Step 0" at 
http://dev.chromium.org/blink/launching-features
 for a link).

Also, out of curiosity (because I don't know much about scrollbars) - will this 
proposed change have an impact on a page's layout?

thanks,
Mike

On 1/28/22 2:50 PM, 'Rahul Arakeri' via blink-dev wrote:

Intent to implement: Fluent Scrollbars.

 

Contact emails

Rahul Arakeri: arak...@microsoft.com

Yaroslav Shalivskyy: yshalivs...@microsoft.com

Sahir Vellani: sahir.vell...@microsoft.com

Olga Gerchikov: gerch...@microsoft.com

Ben Mathwig: 
benjamin.math...@microsoft.com



Visual Spec

https://docs.google.com/document/d/1EpJnWAcPCxBQo6zPGR1Tg1NACiIJ-6dk7cYyK1DhBWw/edit



Summary

This proposal is to modernize the Chromium scrollbars (both overlay and 
non-overlay) to fit the Windows 11 Fluent design language. As a part of this 
effort, we are proposing to update the visual appearance along with some 
changes to how users interact with overlay scrollbars.



Motivation

As the rest of Windows has been embracing WinUI and native Fluent controls, 
certain non-XAML apps like Chromium-based browsers still use the traditional 
(Win32 looking) scrollbars. As such, we believe that the visual appearance of 
scrollbars could use an update in the interest of maintaining homogeneity with 
the rest of Windows.

In a nutshell, we’re proposing that the default scrollbars should act more like 
overlay scrollbars, be thinner, have insets and rounded edges. Users will still 
have an option to select non overlay scrollbars via the "Always show 
scrollbars" OS setting. Non overlay scrollbars will also be restyled to match 
Windows theme. For details on scrollbar styling and state transitions, please 
see the visual spec linked above.

Also, please note that since some HTML controls (like  and ) 
depend on the ScrollbarThemes(s) that are being refreshed, they too will also 
get the new scrollbars.



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

No, this is aimed at Windows for now. However, it can be made available on 
Linux too.



Ongoing technical constraints

None.



Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1292117
--
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.go

[blink-dev] Intent to Prototype: AbortSignal.timeout() Static Method

2022-01-28 Thread Scott Haseley 
Contact emailsshase...@chromium.org

Explainerhttps://github.com/whatwg/dom/pull/1032#issue-1058779111

Specificationhttps://github.com/whatwg/dom/pull/1032

Summary

Returns a new AbortSignal object that is automatically aborted after a
given number of milliseconds. This method can be used by developers to
easily implement timeouts for signal-accepting async APIs, e.g. fetch().


Blink componentBlink>DOM


Motivation

The main motivating use case for this is helping web developers easily time
out async operations, such as fetch(). For example, now you can write:
fetch(url, { signal: AbortSignal.timeout(10_000) });


Initial public proposal

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

TAG review statusPending

Risks


Interoperability and Compatibility



Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:


Debuggability

Basic tooling only, i.e. autocomplete support for the new AbortSignal
method will be provided.


Is this feature fully tested by web-platform-tests

?No

Flag name

Requires code in //chrome?False

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

Launch bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1292159

Estimated milestones

No milestones specified


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

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/CAKXGoJ21UGV-atHU38es8AtFC4tYX7PQrMCoq-zObxo36z4ELQ%40mail.gmail.com.

Re: [blink-dev] Intent to implement: Fluent Scrollbars.

2022-01-28 Thread Mike Taylor 

Hi Rahul,

Would you mind creating a chromestatus entry for this intent? (See "Step 
0" at http://dev.chromium.org/blink/launching-features for a link).


Also, out of curiosity (because I don't know much about scrollbars) - 
will this proposed change have an impact on a page's layout?


thanks,
Mike

On 1/28/22 2:50 PM, 'Rahul Arakeri' via blink-dev wrote:


*_Intent to implement: Fluent Scrollbars._*

 

*_Contact emails_*

Rahul Arakeri: arak...@microsoft.com 

Yaroslav Shalivskyy: yshalivs...@microsoft.com 



Sahir Vellani: sahir.vell...@microsoft.com 



Olga Gerchikov: gerch...@microsoft.com 

Ben Mathwig: benjamin.math...@microsoft.com 



*_Visual Spec_*

https://docs.google.com/document/d/1EpJnWAcPCxBQo6zPGR1Tg1NACiIJ-6dk7cYyK1DhBWw/edit 



*_Summary_*

This proposal is to modernize the Chromium scrollbars (both overlay 
and non-overlay) to fit the Windows 11 Fluent design language. As a 
part of this effort, we are proposing to update the visual appearance 
along with some changes to how users interact with overlay scrollbars.


*_Motivation_*

As the rest of Windows has been embracing WinUI and native Fluent 
controls, certain non-XAML apps like Chromium-based browsers still use 
the traditional (Win32 looking) scrollbars. As such, we believe that 
the visual appearance of scrollbars could use an update in the 
interest of maintaining homogeneity with the rest of Windows.


In a nutshell, we’re proposing that the default scrollbars should act 
more like overlay scrollbars, be thinner, have insets and rounded 
edges. Users will still have an option to select non overlay 
scrollbars via the "Always show scrollbars" OS setting. Non overlay 
scrollbars will also be restyled to match Windows theme. For details 
on scrollbar styling and state transitions, please see the visual spec 
linked above.


Also, please note that since some HTML controls (like  and 
) depend on the ScrollbarThemes(s) that are being refreshed, 
they too will also get the new scrollbars.


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


No, this is aimed at Windows for now. However, it can be made 
available on Linux too.


*_Ongoing technical constraints_*

None.

*_Tracking bug_*

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

--
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/SJ0PR00MB1144A4EB417B9D55D9C4D079A6229%40SJ0PR00MB1144.namprd00.prod.outlook.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/a8b056ed-b1bb-ab26-0b29-a4cd72599f4f%40chromium.org.

[blink-dev] Re: Intent to Continue Experimenting: Speculation Rules (Prefetch)

2022-01-28 Thread Jeremy Roman 
On Fri, Jan 28, 2022 at 4:33 AM Yoav Weiss  wrote:

> LGTM to continue experimentation. Note that this would bring the OT to 11
> milestones, which is approaching the limits of OT timelines.
>
> On Wed, Jan 26, 2022 at 9:57 PM Jeremy Roman  wrote:
>
>> On Wed, Jan 26, 2022 at 10:18 AM Yoav Weiss 
>> wrote:
>>
>>> Any current feedback from the OT up until now?
>>>
>>
>> Feedback on the speculation rules API itself has been relatively limited.
>> We had one issue where server postprocessing incorrectly interpreted a
>>

[blink-dev] Intent to implement: Fluent Scrollbars.

2022-01-28 Thread 'Rahul Arakeri' via blink-dev 
Intent to implement: Fluent Scrollbars.

 

Contact emails

Rahul Arakeri: arak...@microsoft.com

Yaroslav Shalivskyy: yshalivs...@microsoft.com

Sahir Vellani: sahir.vell...@microsoft.com

Olga Gerchikov: gerch...@microsoft.com

Ben Mathwig: 
benjamin.math...@microsoft.com



Visual Spec

https://docs.google.com/document/d/1EpJnWAcPCxBQo6zPGR1Tg1NACiIJ-6dk7cYyK1DhBWw/edit



Summary

This proposal is to modernize the Chromium scrollbars (both overlay and 
non-overlay) to fit the Windows 11 Fluent design language. As a part of this 
effort, we are proposing to update the visual appearance along with some 
changes to how users interact with overlay scrollbars.



Motivation

As the rest of Windows has been embracing WinUI and native Fluent controls, 
certain non-XAML apps like Chromium-based browsers still use the traditional 
(Win32 looking) scrollbars. As such, we believe that the visual appearance of 
scrollbars could use an update in the interest of maintaining homogeneity with 
the rest of Windows.

In a nutshell, we’re proposing that the default scrollbars should act more like 
overlay scrollbars, be thinner, have insets and rounded edges. Users will still 
have an option to select non overlay scrollbars via the "Always show 
scrollbars" OS setting. Non overlay scrollbars will also be restyled to match 
Windows theme. For details on scrollbar styling and state transitions, please 
see the visual spec linked above.

Also, please note that since some HTML controls (like  and ) 
depend on the ScrollbarThemes(s) that are being refreshed, they too will also 
get the new scrollbars.



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

No, this is aimed at Windows for now. However, it can be made available on 
Linux too.



Ongoing technical constraints

None.



Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1292117

-- 
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/SJ0PR00MB1144A4EB417B9D55D9C4D079A6229%40SJ0PR00MB1144.namprd00.prod.outlook.com.

Re: [blink-dev] Intent to Ship: Capability Delegation with Payment Request

2022-01-28 Thread Chris Harrelson 
On Fri, Jan 28, 2022 at 9:01 AM Stephen Mcgruer 
wrote:

> > Am I correct that currently Chromium allows the Payment Request API to
> be used unconditionally in iframes? Do you then intend to send another
> intent to change the behavior to require activation, after a suitable
> period and working with sites to migrate?
>
> Correct. This is Intent to Deprecate and Remove: Calling
> PaymentRequest.show without user activation
> 
> .
>

LOL. I feel like I might have LGTMed that one.


> We had hoped to land them simultaneously (as we have a good relationship
> with the primary user that does not currently have user-activation when
> calling show()), however our partner is having trouble with their
> migration and we may request to push the enforcement (aka the deprecation)
> back to M102. (TBD still; I expect to make the request on the deprecation
> thread in the next few days.)
>

SGTM!

LGTM3 for this intent (shipping the API).


>
> On Fri, 28 Jan 2022 at 11:55, Chris Harrelson 
> wrote:
>
>> I'm a bit confused about the bit regarding transitioning existing sites.
>> Am I correct that currently Chromium allows the Payment Request API to be
>> used unconditionally in iframes? Do you then intend to send another intent
>> to change the behavior to require activation, after a suitable period and
>> working with sites to migrate?
>>
>> Chris
>>
>> On Thu, Jan 27, 2022 at 11:13 PM Yoav Weiss 
>> wrote:
>>
>>> LGTM2 % fixing the spec issue.
>>>
>>> On Thu, Jan 27, 2022 at 9:53 PM Mike Taylor 
>>> wrote:
>>>
 Appreciate the replies, Mustaq.

 This seems like a useful addition to the platform, thanks for working
 on it. LGTM1.

 On 1/27/22 12:35 PM, Mustaq Ahmed wrote:

 Hi Mike:

 Appreciate your feedback.  My answers are inline.

 Mustaq


 On Wed, Jan 26, 2022 at 6:03 PM Mike Taylor 
 wrote:

> Hi Mustaq,
>
> On 1/25/22 4:45 PM, Mustaq Ahmed wrote:
>
> Contact emails
>
> mus...@chromium.org, smcgr...@chromium.org
> Explainer
>
> https://github.com/WICG/capability-delegation
> Specification
>
> https://wicg.github.io/capability-delegation/spec.html
> Design doc
>
>
> https://docs.google.com/document/d/1IYN0mVy7yi4Afnm2Y0uda0JH8L2KwLgaBqsMVLMYXtk/edit?usp=sharing
> Summary
>
> Capability delegation means allowing a frame to relinquish its ability
> to call a restricted API and transfer the ability to another (sub)frame it
> trusts.
>
> Can you expand more on the relinquishing aspect and how regaining the
> capability happens? I can't find any normative text in
> https://wicg.github.io/capability-delegation/spec.html that explains
> how it happens. Do we look for expired timestamps in
> DELEGATED_CAPABILITY_TIMESTAMPS["feature"] of all frames? Something else?
>
> (maybe I'm looking in the wrong place!)
>
 You got it right: our proposal missed the normative text around the
 relinquishing, yikes!  I opened this spec issue
 , we will
 send out a PR to fix this when we get a chance.  In the meantime here is
 what we wanted to mean: access to activation-gated APIs
 
  is
 lost from the sender frame through consumption, and the receiver frame
 checks its own DELEGATED_CAPABILITY_TIMESTAMPS["feature"] only.

 If an app wants to delegate its ability to call a restricted JS
> capability (e.g. popups, fullscreen, etc) to a known+trusted third-party
> frame, the app would utilize a Capability Delegation API to "transfer" the
> ability to the target frame in a time-constrained manner (unlike static
> mechanisms like  attributes).
>
> What happens if the delegation is refused (or fails) by the browser
> for some reason? As a developer, how do I know that I shouldn't fire off a
> PaymentRequest that's going to fail? Do we signal anything in the message
> event, if not, should we?
>
> (From the PaymentRequest side, I guess I can handle the failure if
> PaymentRequest.show() is rejected.)
>
 Yes, just trying PaymentRequest.show() works on the receiver side
 today.  As we get more use-cases around delegation, we can explore
 signaling on the received message event.  I would suggest starting a new
 issue to discuss this.

 That's fair - I'll file an issue, but I don't consider this to be a
 blocking concern.


 As for error handling on the sender side, we have a few synchronous
 failure conditions in our postMessage
 
  algorithm

Re: [blink-dev] Intent to Ship: Capability Delegation with Payment Request

2022-01-28 Thread Stephen Mcgruer 
> Am I correct that currently Chromium allows the Payment Request API to be
used unconditionally in iframes? Do you then intend to send another intent
to change the behavior to require activation, after a suitable period and
working with sites to migrate?

Correct. This is Intent to Deprecate and Remove: Calling
PaymentRequest.show without user activation
.
We had hoped to land them simultaneously (as we have a good relationship
with the primary user that does not currently have user-activation when
calling show()), however our partner is having trouble with their
migration and we may request to push the enforcement (aka the deprecation)
back to M102. (TBD still; I expect to make the request on the deprecation
thread in the next few days.)

On Fri, 28 Jan 2022 at 11:55, Chris Harrelson  wrote:

> I'm a bit confused about the bit regarding transitioning existing sites.
> Am I correct that currently Chromium allows the Payment Request API to be
> used unconditionally in iframes? Do you then intend to send another intent
> to change the behavior to require activation, after a suitable period and
> working with sites to migrate?
>
> Chris
>
> On Thu, Jan 27, 2022 at 11:13 PM Yoav Weiss 
> wrote:
>
>> LGTM2 % fixing the spec issue.
>>
>> On Thu, Jan 27, 2022 at 9:53 PM Mike Taylor 
>> wrote:
>>
>>> Appreciate the replies, Mustaq.
>>>
>>> This seems like a useful addition to the platform, thanks for working on
>>> it. LGTM1.
>>>
>>> On 1/27/22 12:35 PM, Mustaq Ahmed wrote:
>>>
>>> Hi Mike:
>>>
>>> Appreciate your feedback.  My answers are inline.
>>>
>>> Mustaq
>>>
>>>
>>> On Wed, Jan 26, 2022 at 6:03 PM Mike Taylor 
>>> wrote:
>>>
 Hi Mustaq,

 On 1/25/22 4:45 PM, Mustaq Ahmed wrote:

 Contact emails

 mus...@chromium.org, smcgr...@chromium.org
 Explainer

 https://github.com/WICG/capability-delegation
 Specification

 https://wicg.github.io/capability-delegation/spec.html
 Design doc


 https://docs.google.com/document/d/1IYN0mVy7yi4Afnm2Y0uda0JH8L2KwLgaBqsMVLMYXtk/edit?usp=sharing
 Summary

 Capability delegation means allowing a frame to relinquish its ability
 to call a restricted API and transfer the ability to another (sub)frame it
 trusts.

 Can you expand more on the relinquishing aspect and how regaining the
 capability happens? I can't find any normative text in
 https://wicg.github.io/capability-delegation/spec.html that explains
 how it happens. Do we look for expired timestamps in
 DELEGATED_CAPABILITY_TIMESTAMPS["feature"] of all frames? Something else?

 (maybe I'm looking in the wrong place!)

>>> You got it right: our proposal missed the normative text around the
>>> relinquishing, yikes!  I opened this spec issue
>>> , we will send
>>> out a PR to fix this when we get a chance.  In the meantime here is what we
>>> wanted to mean: access to activation-gated APIs
>>> 
>>>  is
>>> lost from the sender frame through consumption, and the receiver frame
>>> checks its own DELEGATED_CAPABILITY_TIMESTAMPS["feature"] only.
>>>
>>> If an app wants to delegate its ability to call a restricted JS
 capability (e.g. popups, fullscreen, etc) to a known+trusted third-party
 frame, the app would utilize a Capability Delegation API to "transfer" the
 ability to the target frame in a time-constrained manner (unlike static
 mechanisms like  attributes).

 What happens if the delegation is refused (or fails) by the browser for
 some reason? As a developer, how do I know that I shouldn't fire off a
 PaymentRequest that's going to fail? Do we signal anything in the message
 event, if not, should we?

 (From the PaymentRequest side, I guess I can handle the failure if
 PaymentRequest.show() is rejected.)

>>> Yes, just trying PaymentRequest.show() works on the receiver side
>>> today.  As we get more use-cases around delegation, we can explore
>>> signaling on the received message event.  I would suggest starting a new
>>> issue to discuss this.
>>>
>>> That's fair - I'll file an issue, but I don't consider this to be a
>>> blocking concern.
>>>
>>>
>>> As for error handling on the sender side, we have a few synchronous
>>> failure conditions in our postMessage
>>> 
>>>  algorithm
>>> 
>>>  already,
>>> can easily new ones as needed.  However, if you are thinking about an
>>> asynchronous failure (e.g. detected later when the browser decided to run
>>> the posted task), it seems like an existing problem with postMessage unless
>>>

Re: [blink-dev] Intent to Prototype: Transferable MediaStreamTracks

2022-01-28 Thread Kamila Hasanbega 
Hey Tony,

Can you please confirm that if the target context is destroyed, or calls 
MediaStreamTrack.stop(), that will stop the source, unless other 
MediaStreamTrack objects depend on it, just like in the non-transferred 
case. See: 
https://www.w3.org/TR/mediacapture-streams/#dom-mediastreamtrack-stop

In addition, please provide a practical example where it makes sense to 
pass the track between cross-origin windows.

- Kamila 

On Tuesday, January 25, 2022 at 10:52:38 AM UTC+1 Mike West wrote:

> Hey Tony!
>
> My understanding of the transfer mechanism is that the transferring 
> context loses control of the stream, handing it off to the receiving 
> context. The stream source remains with the original context, however, and 
> I'm wondering whether that provides an opportunity for replicating the 
> timing attacks that SharedArrayBuffers enabled 
> .
>  
> Given the ability to clone streams, it seems possible for a source in one 
> context to be writeable in one context, and readable from multiple contexts.
>
> Have y'all thought about that potential threat? Is it actually a risk, or 
> have I missed things? :)
>
> /cc +Artur Janc 
>
> -mike
>
>
> On Wed, Jan 19, 2022 at 5:07 PM 'Tony Herre' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> Contact emailshe...@google.com, h...@chromium.org
>>
>> ExplainerNone
>>
>> Specification
>> https://w3c.github.io/mediacapture-extensions/#transferable-mediastreamtrack
>>
>> Summary
>>
>> Expose MediaStreamTracks in Workers and allow them to be transferred 
>> between contexts. Allowing this transfer makes it easier to access and 
>> process media in contexts other that where it was created, eg in Workers or 
>> other documents.
>>
>>
>> Blink componentBlink>MediaStream 
>> 
>>
>> Motivation
>>
>> Having transferable MediaStreamTracks allows much more flexibility for 
>> architecting web applications which have multiple windows which each wish 
>> to contribute video or audio tracks to a single WebRTC conference, without 
>> having to have independent competing network connections via 
>> PeerConnection. This also allows transferring all media processing to a 
>> separate context eg a worker, rather than mediating control signals through 
>> the window.
>>
>>
>> Initial public proposal
>>
>> TAG review
>>
>> TAG review statusNot applicable
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>>
>>
>> Gecko: No signal
>> Positive in WebRTC Working Group discussions
>>
>> WebKit: No signal
>> Positive in WebRTC Working Group discussions
>>
>> Web developers: No signals
>>
>> Other signals:
>>
>>
>>
>> Debuggability
>>
>>
>>
>> Is this feature fully tested by web-platform-tests 
>> 
>> ?No
>>
>> Flag name
>>
>> Requires code in //chrome?False
>>
>> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1288839
>>
>> Estimated milestones
>>
>> No milestones specified
>>
>>
>> Link to entry on the Chrome Platform Status
>> https://chromestatus.com/feature/5747241384935424
>>
>> 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/CAArnMxEAdAdKs-T5o_TWCnvXpWEXiXDvpoxz_zpwADn%2BpyBwEA%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/459966d1-1d71-4e14-b6bb-d71250707795n%40chromium.org.

Re: [blink-dev] Intent to Ship: Capability Delegation with Payment Request

2022-01-28 Thread Chris Harrelson 
I'm a bit confused about the bit regarding transitioning existing sites. Am
I correct that currently Chromium allows the Payment Request API to be used
unconditionally in iframes? Do you then intend to send another intent to
change the behavior to require activation, after a suitable period and
working with sites to migrate?

Chris

On Thu, Jan 27, 2022 at 11:13 PM Yoav Weiss  wrote:

> LGTM2 % fixing the spec issue.
>
> On Thu, Jan 27, 2022 at 9:53 PM Mike Taylor 
> wrote:
>
>> Appreciate the replies, Mustaq.
>>
>> This seems like a useful addition to the platform, thanks for working on
>> it. LGTM1.
>>
>> On 1/27/22 12:35 PM, Mustaq Ahmed wrote:
>>
>> Hi Mike:
>>
>> Appreciate your feedback.  My answers are inline.
>>
>> Mustaq
>>
>>
>> On Wed, Jan 26, 2022 at 6:03 PM Mike Taylor 
>> wrote:
>>
>>> Hi Mustaq,
>>>
>>> On 1/25/22 4:45 PM, Mustaq Ahmed wrote:
>>>
>>> Contact emails
>>>
>>> mus...@chromium.org, smcgr...@chromium.org
>>> Explainer
>>>
>>> https://github.com/WICG/capability-delegation
>>> Specification
>>>
>>> https://wicg.github.io/capability-delegation/spec.html
>>> Design doc
>>>
>>>
>>> https://docs.google.com/document/d/1IYN0mVy7yi4Afnm2Y0uda0JH8L2KwLgaBqsMVLMYXtk/edit?usp=sharing
>>> Summary
>>>
>>> Capability delegation means allowing a frame to relinquish its ability
>>> to call a restricted API and transfer the ability to another (sub)frame it
>>> trusts.
>>>
>>> Can you expand more on the relinquishing aspect and how regaining the
>>> capability happens? I can't find any normative text in
>>> https://wicg.github.io/capability-delegation/spec.html that explains
>>> how it happens. Do we look for expired timestamps in
>>> DELEGATED_CAPABILITY_TIMESTAMPS["feature"] of all frames? Something else?
>>>
>>> (maybe I'm looking in the wrong place!)
>>>
>> You got it right: our proposal missed the normative text around the
>> relinquishing, yikes!  I opened this spec issue
>> , we will send
>> out a PR to fix this when we get a chance.  In the meantime here is what we
>> wanted to mean: access to activation-gated APIs
>> 
>>  is
>> lost from the sender frame through consumption, and the receiver frame
>> checks its own DELEGATED_CAPABILITY_TIMESTAMPS["feature"] only.
>>
>> If an app wants to delegate its ability to call a restricted JS
>>> capability (e.g. popups, fullscreen, etc) to a known+trusted third-party
>>> frame, the app would utilize a Capability Delegation API to "transfer" the
>>> ability to the target frame in a time-constrained manner (unlike static
>>> mechanisms like  attributes).
>>>
>>> What happens if the delegation is refused (or fails) by the browser for
>>> some reason? As a developer, how do I know that I shouldn't fire off a
>>> PaymentRequest that's going to fail? Do we signal anything in the message
>>> event, if not, should we?
>>>
>>> (From the PaymentRequest side, I guess I can handle the failure if
>>> PaymentRequest.show() is rejected.)
>>>
>> Yes, just trying PaymentRequest.show() works on the receiver side
>> today.  As we get more use-cases around delegation, we can explore
>> signaling on the received message event.  I would suggest starting a new
>> issue to discuss this.
>>
>> That's fair - I'll file an issue, but I don't consider this to be a
>> blocking concern.
>>
>>
>> As for error handling on the sender side, we have a few synchronous
>> failure conditions in our postMessage
>> 
>>  algorithm
>> 
>>  already,
>> can easily new ones as needed.  However, if you are thinking about an
>> asynchronous failure (e.g. detected later when the browser decided to run
>> the posted task), it seems like an existing problem with postMessage unless
>> we change it to return a Promise
>>  (a separate problem).
>>
>>> Blink component
>>>
>>> Blink>Input
>>> 
>>> TAG review
>>>
>>> https://github.com/w3ctag/design-reviews/issues/655
>>> TAG review status
>>>
>>> Approved subject to minor changes.
>>>
>>> (Work in progress, see
>>> https://github.com/WICG/capability-delegation/pull/23).
>>> Risks Interoperability
>>>
>>> Interop risk here like any new API: new use-cases relying on delegation
>>> will fail in a browser that hasn't implemented this feature.  In such a
>>> browser, the new API (postMessage() call with an additional option)
>>> will silently get ignored while preserving the legacy behavior.  More
>>> precisely, the postMessage() call will be treated as if it was meant to
>>> send the message object only, and the delegated capability will behave in
>>> the target Window as if no delegation has taken place.
>>>
>>>

[blink-dev] Re: Intent to Continue Experimenting: Speculation Rules (Prefetch)

2022-01-28 Thread Yoav Weiss 
LGTM to continue experimentation. Note that this would bring the OT to 11
milestones, which is approaching the limits of OT timelines.

On Wed, Jan 26, 2022 at 9:57 PM Jeremy Roman  wrote:

> On Wed, Jan 26, 2022 at 10:18 AM Yoav Weiss 
> wrote:
>
>> Any current feedback from the OT up until now?
>>
>
> Feedback on the speculation rules API itself has been relatively limited.
> We had one issue where server postprocessing incorrectly interpreted a
>