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

[Chris Harrelson]

On Thu, Feb 3, 2022, 10:00 PM 'Rahul Arakeri' via blink-dev <
blink-dev@chromium.org> wrote:

> Just checking in on this.. Please let us know if you need anything from us
> to move this discussion along.
>

Hi Rahul,

Since this is an intent to implement you don't need any official approval
from an API owner. Feel free to start landing code. Let me know if you run
into any issues, happy to help unblock progress.

>
> Thanks,
>
> Rahul
>
>
>
> *From:* Rahul Arakeri
> *Sent:* Tuesday, February 1, 2022 11:43 AM
> *To:* 'Steve Kobes' 
> *Cc:* Chris Harrelson ; Ian Kilpatrick <
> ikilpatr...@chromium.org>; Mike Taylor ;
> blink-dev@chromium.org; Robert Flack ; wangxianzhu <
> wangxian...@chromium.org>; p...@chromium.org; input-...@chromium.org;
> Yaroslav Shalivskyy ; Olga Gerchikov <
> gerch...@microsoft.com>; Sahir Vellani ; Ben
> Mathwig 
> *Subject:* RE: [EXTERNAL] Re: [blink-dev] Intent to implement: Fluent
> Scrollbars.
>
>
>
> Re Steve: For Linux, we don't have a strong preference on the default
> scrollbar mode (and we don’t yet know the scope of work needed since we
> never tested this feature on Linux).
>
> For Windows however, we recommend having minimal mode as the default as
> outlined in the visual spec
> 
> .
>
>
>
> Re all: Please let us know if we all have consensus on the visual styling
> 
> of the scrollbars. If you want to see the feature in action, please feel
> free to check out Microsoft Edge Canary
> .
> (Experimental flag *edge://flags/#edge-overlay-scrollbars-win-style*).
>
>
>
> *From:* Steve Kobes 
> *Sent:* Monday, January 31, 2022 11:38 AM
> *To:* Rahul Arakeri 
> *Cc:* Chris Harrelson ; Ian Kilpatrick <
> ikilpatr...@chromium.org>; Mike Taylor ;
> blink-dev@chromium.org; Robert Flack ; wangxianzhu <
> wangxian...@chromium.org>; p...@chromium.org; input-...@chromium.org;
> Yaroslav Shalivskyy ; Olga Gerchikov <
> gerch...@microsoft.com>; Sahir Vellani ; Ben
> Mathwig 
> *Subject:* Re: [EXTERNAL] Re: [blink-dev] Intent to implement: Fluent
> Scrollbars.
>
>
>
> Keeping non-overlay by default on Linux would be one way to mitigate the
> risk that Ian mentions, namely that bugs specific to non-overlay mode may
> creep in and not be noticed quickly.  (This concern applies to some degree
> both to bugs in websites, and bugs in Chrome.)
>
>
>
> On Mon, Jan 31, 2022 at 2:23 PM 'Rahul Arakeri' via input-dev <
> input-...@chromium.org> wrote:
>
> Thanks Ian :)
>
>
>
> Re Chris:
>
> There will be some OS wiring missing (like switching between dark/light
> modes, "Always show scrollbars”, etc) but most of the code should just
> work. Note that we've never really tested this feature on Linux so we do
> not have an exhaustive list of stuff that will not work on Linux.
>
>
>
> *From:* Chris Harrelson 
> *Sent:* Friday, January 28, 2022 3:45 PM
> *To:* Ian Kilpatrick 
> *Cc:* Rahul Arakeri ; Mike Taylor <
> miketa...@chromium.org>; blink-dev@chromium.org; Robert Flack <
> fla...@chromium.org>; wangxianzhu ;
> p...@chromium.org; input-...@chromium.org; Yaroslav Shalivskyy <
> yshalivs...@microsoft.com>; Olga Gerchikov ;
> Sahir Vellani ; Ben Mathwig <
> benjamin.math...@microsoft.com>
> *Subject:* Re: [EXTERNAL] Re: [blink-dev] Intent to implement: Fluent
> Scrollbars.
>
>
>
> 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
> 

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

['Rahul Arakeri' via blink-dev]

Just checking in on this.. Please let us know if you need anything from us to 
move this discussion along.

Thanks,
Rahul

From: Rahul Arakeri
Sent: Tuesday, February 1, 2022 11:43 AM
To: 'Steve Kobes' 
Cc: Chris Harrelson ; Ian Kilpatrick 
; Mike Taylor ; 
blink-dev@chromium.org; Robert Flack ; wangxianzhu 
; p...@chromium.org; input-...@chromium.org; Yaroslav 
Shalivskyy ; Olga Gerchikov 
; Sahir Vellani ; Ben 
Mathwig 
Subject: RE: [EXTERNAL] Re: [blink-dev] Intent to implement: Fluent Scrollbars.

Re Steve: For Linux, we don't have a strong preference on the default scrollbar 
mode (and we don’t yet know the scope of work needed since we never tested this 
feature on Linux).
For Windows however, we recommend having minimal mode as the default as 
outlined in the visual 
spec.

Re all: Please let us know if we all have consensus on the visual 
styling
 of the scrollbars. If you want to see the feature in action, please feel free 
to check out Microsoft Edge 
Canary. 
(Experimental flag edge://flags/#edge-overlay-scrollbars-win-style).

From: Steve Kobes mailto:sko...@chromium.org>>
Sent: Monday, January 31, 2022 11:38 AM
To: Rahul Arakeri mailto:arak...@microsoft.com>>
Cc: Chris Harrelson mailto:chris...@chromium.org>>; Ian 
Kilpatrick mailto:ikilpatr...@chromium.org>>; Mike 
Taylor mailto:miketa...@chromium.org>>; 
blink-dev@chromium.org; Robert Flack 
mailto:fla...@chromium.org>>; wangxianzhu 
mailto:wangxian...@chromium.org>>; 
p...@chromium.org; 
input-...@chromium.org; Yaroslav Shalivskyy 
mailto:yshalivs...@microsoft.com>>; Olga Gerchikov 
mailto:gerch...@microsoft.com>>; Sahir Vellani 
mailto:sahir.vell...@microsoft.com>>; Ben Mathwig 
mailto:benjamin.math...@microsoft.com>>
Subject: Re: [EXTERNAL] Re: [blink-dev] Intent to implement: Fluent Scrollbars.

Keeping non-overlay by default on Linux would be one way to mitigate the risk 
that Ian mentions, namely that bugs specific to non-overlay mode may creep in 
and not be noticed quickly.  (This concern applies to some degree both to bugs 
in websites, and bugs in Chrome.)

On Mon, Jan 31, 2022 at 2:23 PM 'Rahul Arakeri' via input-dev 
mailto:input-...@chromium.org>> wrote:
Thanks Ian :)

Re Chris:
There will be some OS wiring missing (like switching between dark/light modes, 
"Always show scrollbars”, etc) but most of the code should just work. Note that 
we've never really tested this feature on Linux so we do not have an exhaustive 
list of stuff that will not work on Linux.

From: Chris Harrelson mailto:chris...@chromium.org>>
Sent: Friday, January 28, 2022 3:45 PM
To: Ian Kilpatrick mailto:ikilpatr...@chromium.org>>
Cc: Rahul Arakeri mailto:arak...@microsoft.com>>; Mike 
Taylor mailto:miketa...@chromium.org>>; 
blink-dev@chromium.org; Robert Flack 
mailto:fla...@chromium.org>>; wangxianzhu 
mailto:wangxian...@chromium.org>>; 
p...@chromium.org; 
input-...@chromium.org; Yaroslav Shalivskyy 
mailto:yshalivs...@microsoft.com>>; Olga Gerchikov 
mailto:gerch...@microsoft.com>>; Sahir Vellani 
mailto:sahir.vell...@microsoft.com>>; Ben Mathwig 
mailto:benjamin.math...@microsoft.com>>
Subject: Re: [EXTERNAL] Re: [blink-dev] Intent to implement: Fluent Scrollbars.

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 
mailto:ikilpatr...@chromium.org>> 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 
mailto:blink-dev@chromium.org>> wrote:
Hi Mike,

Sure, I’ve created a chromestatus entry here: 

Re: [blink-dev] Intent to Deprecate and Remove: Support for filesystem URLs on Android media

[Mike Taylor]

On 2/3/22 8:37 PM, Nigel Tao wrote:

On Thu, Jan 27, 2022 at 3:23 AM Brianna Goldstein
 wrote:

On Thu, Jan 27, 2022 at 2:49 AM Yoav Weiss  wrote:

At the risk of piling on with another question: are these URLs different from 
`file://` scheme URLs?

@Yoav Weiss yes these are from the `filesystem://` scheme which is different 
from `file://`. Here's some information about where this scheme comes from.

I'll ask another naive question...

I understand "file://" URLs. "file:///home/user/bar.txt" is an example.

Can you give some examples of "filesystem://" URLs? Do they look like
"filesystem:///home/user/bar.txt" or
"filesystem://example.domain/foo/bar.txt" or something else? Do these
URLs look different for Android versus Desktop? Do they look different
for Browser App versus Web View?


Here's some sample code to illustrate how to get a filesystem URL: 
https://gist.github.com/miketaylr/df58ae669abc4eec1b514f4cfc71fc21 - 
pasted below as well


```

function writeFile(fs) {
  fs.root.getFile("coolguy.txt", {create: true}, fileEntry => {
    fileEntry.createWriter(fileWriter => {
  fileWriter.onwriteend = e => {
    window.webkitRequestFileSystem(window.TEMPORARY, 1024, readFile);
  };
  fileWriter.write(new Blob([""], {type: "text/plain"}));
    });
  });
}

function readFile(fs) {
  fs.root.getFile("coolguy.txt", {}, fileEntry => {
    fileEntry.file(file => {
  const reader = new FileReader();
  reader.onloadend = e => {
    console.log(e, fileEntry.toURL());
  };
  reader.readAsText(file);
    });
  });
}

navigator.webkitTemporaryStorage.requestQuota(1024, granted => {
  window.webkitRequestFileSystem(window.TEMPORARY, granted, writeFile);
});

```

--
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/35b0b3cc-26bd-b44e-8e1e-0e05d7ac11dd%40chromium.org.

Re: [blink-dev] Intent to Deprecate and Remove: Support for filesystem URLs on Android media

[Nigel Tao]

On Thu, Jan 27, 2022 at 3:23 AM Brianna Goldstein
 wrote:
>On Thu, Jan 27, 2022 at 2:49 AM Yoav Weiss  wrote:
>> At the risk of piling on with another question: are these URLs different 
>> from `file://` scheme URLs?
>
> @Yoav Weiss yes these are from the `filesystem://` scheme which is different 
> from `file://`. Here's some information about where this scheme comes from.

I'll ask another naive question...

I understand "file://" URLs. "file:///home/user/bar.txt" is an example.

Can you give some examples of "filesystem://" URLs? Do they look like
"filesystem:///home/user/bar.txt" or
"filesystem://example.domain/foo/bar.txt" or something else? Do these
URLs look different for Android versus Desktop? Do they look different
for Browser App versus Web View?

Your "Here's" link points to
https://www.iana.org/assignments/uri-schemes/historic/filesystem which
doesn't give an example, nor does the
https://www.w3.org/TR/file-system-api/ or
http://www.html5rocks.com/en/tutorials/file/filesystem/ (which
redirects to https://web.dev/read-files/) links from its references.

pwnall@ later linked to
https://dev.w3.org/2009/dap/file-system/file-dir-sys.html and
https://wicg.github.io/file-system-access/ and the only example URL is
"Proposal currently under discussion: Use a format such as
filesystem:http://example.domain/persistent-or-temporary/path/to/file.html;
but even if it's more than a proposal, I'm not sure if that's a legit
URL if it doesn't have a double-slash after the first colon.

-- 
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/CAEdON6acwSf5c2uJ7ZWgJa32q7tnj%2B%2Bcobqc5Mw3ksu2pFUHXg%40mail.gmail.com.

Re: [blink-dev] Intent to Ship: Digital Goods API v2.0

[Rouslan Solomakhin]

> Are you able to share which groups specifically you've talked with about
this proposal?
> Perhaps just naming them would help?

The browsers (and stores) that we had engaged were Oculus Browser (Oculus
Store), Samsung Internet browser (Samsung Galaxy Store), Safari (Apple App
Store), and Edge (Microsoft Store). Our vision is that -- eventually -- a
PWA installed from any of these stores and running in any of those
browsers, could have the ability to use the same DGAPI calls for in-app
purchases and subscriptions.

On Thu, Feb 3, 2022 at 12:25 PM Rick Byers  wrote:

> On Thu, Feb 3, 2022 at 11:45 AM Rouslan Solomakhin 
> wrote:
>
>> > There are lots of stores, and also several browsers based on
>> > Chromium. Have we talked to them? Is anyone interested in
>> > adding support for this?
>>
>> Yes, we have talked to the other browsers and stores. We have received
>> some questions and no objections. So far, there are no public signals that
>> any other browser has concrete plans to implement DGAPI.
>>
>
> Are you able to share which groups specifically you've talked with about
> this proposal? I've seen that there's been a serious attempt to engage
> others but I understand Rego's perspective that it's not clear from the
> public information how serious we are about that. Perhaps just naming them
> would help?
>
> We discussed this in the API owners meeting yesterday. +Alex Russell
>  mentioned that he would look into what he
> could say from a Microsoft perspective. There were no objections to
> shipping in the meeting (API owners present IIRC were Alex, Yoav, Chris,
> Daniel, Rick, Mike Taylor and Mike West). So with my LGTM3, you're approved
> to ship Rouslan. But continuing the discussion on whether there's more we
> can be doing to accelerate and increase the chance of this having multiple
> implementations is great.
>
> > There are also mentions to v2.0 and v2.1.
>> > Which one would be shipping?
>>
>> We would like to ship 2.0 to stable. The 2.1 changes
>> 
>> are non-breaking (only additive) and feature-detectable. These would be
>> coming several milestones after 2.0 ships.
>>
>> > Are you expecting more changes on the API in the short term?
>>
>> As with anything, it's hard to say for sure, but it is possible that 2.2
>> may eventually come out.
>>
>> > It might be hard to implement those changes once it's shipped.
>>
>> What kind of difficulties do you foresee? In my (admittedly small) past
>> experience, the web platform has the ability to carefully iterate on
>> shipped features, if the need arises.
>>
>> > It looks like the spec PR hasn't been merged yet
>> > (https://github.com/WICG/digital-goods/pull/40).
>>
>> https://wicg.github.io/digital-goods/ is the snapshot of what we would
>> like to ship, while the pull request at
>> https://github.com/WICG/digital-goods/pull/40 has been left open for a
>> spec mentor to review it and leave any comments that they may have. (Pull
>> requests on GitHub have convenient features for reviews like that.)
>>
>> > I'd love to understand better the efforts to convince other browsers
>> > and stores about the benefits of this API.
>>
>> We reached out widely during the 2021 TPAC, in the PWA Dev Sync meeting
>> in January of 2022, through bug trackers, and in personal communications.
>> The reception has been mostly neutral so far. I suspect that other members
>> of the ecosystem would like to see DGAPI succeed with web developers before
>> they invest their own resources into it, which makes sense on some level.
>>
>> On Thu, Feb 3, 2022 at 6:01 AM Manuel Rego Casasnovas 
>> wrote:
>>
>>>
>>>
>>> On 02/02/2022 16:51, Rouslan Solomakhin wrote:
>>> >> Rouslan, it looks to me like the API is designed to support multiple
>>> > stores, right?
>>> >> For example if Samsung decided that they wanted to support connecting
>>> > it up to
>>> >> both the Android Play Billing API (so SBrowser could provide
>>> > equivalent user
>>> >> experience to Chrome) AND to the Samsung store (so merchants could
>>> have
>>> >> a choice in stores, perhaps competing on terms like commission rate)
>>> they
>>> >> could do that with the current API shape, right?
>>> >
>>> > That is correct. The API shape has been generalized enough to be
>>> > store-agnostic and browser-agnostic. We have
>>> > <
>>> https://docs.google.com/document/d/1X2j1wKC2T4RONcUGYxGus8Dytv6s2_tVTUSkWDWPza4/edit#heading=h.chc35okxwb9
>>> >
>>> > been  pitching
>>> the
>>> > API to other stores and browsers as well.
>>>
>>> It'd be really nice to get some engagement from other browsers or
>>> stores. There are lots of stores, and also several browsers based on
>>> Chromium. Have we talked to them? Is anyone interested in adding support
>>> for this?
>>>
>>> There are also mentions to v2.0 and v2.1. Which one would be shipping?
>>> Are you expecting more changes on the API in the 

Re: [blink-dev] testing CH-UA

[Ян Стахеев]

Thank you for this clarifacation!

среда, 2 февраля 2022 г. в 23:40:00 UTC+3, mike...@chromium.org: 

> Привет Ян!
>
> If using the devtools mobile emulation, you can add a custom device and 
> there is a toggle to open the "User agent client hints" section where you 
> can add header values: https://i.imgur.com/9vazymM.png. We should 
> probably add sensible defaults to the mobile emulation options, I filed 
> https://bugs.chromium.org/p/chromium/issues/detail?id=1293477 to track 
> that work.
>
> thanks,
> Mike
>
> On 2/2/22 2:41 PM, Ali Beyad wrote:
>
> Hello:
>
> On Wed, Feb 2, 2022 at 1:21 PM Ян Стахеев  wrote:
>
>> Hi!  
>> I'm looking for a way to test Client Hints and to understand how CH will 
>> work on my site before UA will be reduced. For now I use  
>> #reduce-user-agent flag  disabling UA. Is blocking UA by the flag is 
>> enought to see the impact of UA reduction?
>>
>
> Yes, if you enable chrome://flags#reduce-user-agent, your browser will 
> send the reduced UA string to all sites it visits.  Another option if 
> you're a site developer is to participate in our UA reduction origin trial: 
> https://developer.chrome.com/blog/user-agent-reduction-origin-trial/
>
> Also I can't fully model the situation in ChromeDev tools. When emulating 
>> the mobile version in ChromeDev tools, CH-UA are not displayed at all. 
>> Could you advise me, please, the reliable way I could test disabling the 
>> User-Agent and using CH on my site in order to understand that all ads, 
>> blocks, etc. will work correctly after disabling UA? Or just using the flag 
>> is pretty enought?
>>
>
> If you just want to test your site from your browser, enabling 
> chrome://flags#reduce-user-agent and changing your site to send Accept-CH 
> headers with the client hints you want should be enough.  If you want to 
> test your site with others who visit it, you can participate in the origin 
> trial linked to above.
>
> Hope this helps!
>
> Thank you! :)
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to blink-dev+...@chromium.org.
>> To view this discussion on the web visit 
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b5da6ca4-752a-40fc-908c-bc902abe12b7n%40chromium.org
>>  
>> 
>> .
>>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to blink-dev+...@chromium.org.
>
> To view this discussion on the web visit 
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BWdJ_6wt-J72dSCSXAakfiT4wDrUjqm6dsGd%2BC-ZEiAT_n2%3DA%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/5286360b-b908-46aa-ba7d-df4d5311ada1n%40chromium.org.

Re: [blink-dev] Intent to Ship: Digital Goods API v2.0

[Rick Byers]

On Thu, Feb 3, 2022 at 11:45 AM Rouslan Solomakhin 
wrote:

> > There are lots of stores, and also several browsers based on
> > Chromium. Have we talked to them? Is anyone interested in
> > adding support for this?
>
> Yes, we have talked to the other browsers and stores. We have received
> some questions and no objections. So far, there are no public signals that
> any other browser has concrete plans to implement DGAPI.
>

Are you able to share which groups specifically you've talked with about
this proposal? I've seen that there's been a serious attempt to engage
others but I understand Rego's perspective that it's not clear from the
public information how serious we are about that. Perhaps just naming them
would help?

We discussed this in the API owners meeting yesterday. +Alex Russell
 mentioned that he would look into what he could
say from a Microsoft perspective. There were no objections to shipping in
the meeting (API owners present IIRC were Alex, Yoav, Chris, Daniel, Rick,
Mike Taylor and Mike West). So with my LGTM3, you're approved to ship
Rouslan. But continuing the discussion on whether there's more we can be
doing to accelerate and increase the chance of this having multiple
implementations is great.

> There are also mentions to v2.0 and v2.1.
> > Which one would be shipping?
>
> We would like to ship 2.0 to stable. The 2.1 changes
> 
> are non-breaking (only additive) and feature-detectable. These would be
> coming several milestones after 2.0 ships.
>
> > Are you expecting more changes on the API in the short term?
>
> As with anything, it's hard to say for sure, but it is possible that 2.2
> may eventually come out.
>
> > It might be hard to implement those changes once it's shipped.
>
> What kind of difficulties do you foresee? In my (admittedly small) past
> experience, the web platform has the ability to carefully iterate on
> shipped features, if the need arises.
>
> > It looks like the spec PR hasn't been merged yet
> > (https://github.com/WICG/digital-goods/pull/40).
>
> https://wicg.github.io/digital-goods/ is the snapshot of what we would
> like to ship, while the pull request at
> https://github.com/WICG/digital-goods/pull/40 has been left open for a
> spec mentor to review it and leave any comments that they may have. (Pull
> requests on GitHub have convenient features for reviews like that.)
>
> > I'd love to understand better the efforts to convince other browsers
> > and stores about the benefits of this API.
>
> We reached out widely during the 2021 TPAC, in the PWA Dev Sync meeting in
> January of 2022, through bug trackers, and in personal communications. The
> reception has been mostly neutral so far. I suspect that other members of
> the ecosystem would like to see DGAPI succeed with web developers before
> they invest their own resources into it, which makes sense on some level.
>
> On Thu, Feb 3, 2022 at 6:01 AM Manuel Rego Casasnovas 
> wrote:
>
>>
>>
>> On 02/02/2022 16:51, Rouslan Solomakhin wrote:
>> >> Rouslan, it looks to me like the API is designed to support multiple
>> > stores, right?
>> >> For example if Samsung decided that they wanted to support connecting
>> > it up to
>> >> both the Android Play Billing API (so SBrowser could provide
>> > equivalent user
>> >> experience to Chrome) AND to the Samsung store (so merchants could have
>> >> a choice in stores, perhaps competing on terms like commission rate)
>> they
>> >> could do that with the current API shape, right?
>> >
>> > That is correct. The API shape has been generalized enough to be
>> > store-agnostic and browser-agnostic. We have
>> > <
>> https://docs.google.com/document/d/1X2j1wKC2T4RONcUGYxGus8Dytv6s2_tVTUSkWDWPza4/edit#heading=h.chc35okxwb9
>> >
>> > been  pitching the
>> > API to other stores and browsers as well.
>>
>> It'd be really nice to get some engagement from other browsers or
>> stores. There are lots of stores, and also several browsers based on
>> Chromium. Have we talked to them? Is anyone interested in adding support
>> for this?
>>
>> There are also mentions to v2.0 and v2.1. Which one would be shipping?
>> Are you expecting more changes on the API in the short term? It might be
>> hard to implement those changes once it's shipped.
>>
>> On the TPAC presentation there was this plan:
>> * Collect feedback from the origin trial.
>> * Publish draft spec in WICG.
>> * Iterate with more developer feedback.
>> * Collaborate with other user agents and app stores.
>> * Ship it.
>>
>> It looks like the spec PR hasn't been merged yet
>> (https://github.com/WICG/digital-goods/pull/40), and I'd love to
>> understand better the efforts to convince other browsers and stores
>> about the benefits of this API.
>>
>> > On Wed, Feb 2, 2022 at 10:31 AM Rick Byers > > > wrote:
>> >
>> > +1 to Yoav's perspective here. Our job 

RE: [EXTERNAL] Re: [blink-dev] Re: Intent to Ship: Pickling for Async Clipboard API

['Anupam Snigdha' via blink-dev]

Discussed offline. Sorry for the delay in response. We are reviewing Mozilla’s 
feedback on the proposal so I 
think we can put this intent on hold for now.

Thanks,
Anupam

From: Yoav Weiss 
Sent: Wednesday, February 2, 2022 2:26 AM
To: blink-dev 
Cc: Yoav Weiss ; Philip Jägenstedt 
; Domenic Denicola ; Chris Harrelson 
; Daniel Bratell ; blink-dev 
; Alex Russell ; Abhishek 
Rathi ; svo...@gmail.com ; Ajay Rahatekar 
; Bo Cupp ; Marijn Kruisselbrink 
; Joshua Bell ; Victor Costan 
; Scott Low ; Anupam Snigdha 

Subject: Re: [EXTERNAL] Re: [blink-dev] Re: Intent to Ship: Pickling for Async 
Clipboard API

Friendly ping! :) Also happy to discuss off-thread in case it's helpful.
On Thursday, January 13, 2022 at 10:25:10 AM UTC+1 Yoav Weiss wrote:
On Wed, Jan 12, 2022 at 8:33 PM Anupam Snigdha 
mailto:sni...@microsoft.com>> wrote:
Hi Philip,

In the worst case we will be able to merge the pickling API 
changes
 into the EditingWG repo. We have a meeting this Friday with the Firefox folks 
to discuss the Pickling API as they were also interested in the 
proposal.
 If we have consensus there, then we will be able to add pickling API to the 
official clipboard spec.
Overall I think the algorithms required to implement Pickling 
API
 is included in the forked PR. There are few concerns regarding sanitization, 
but we couldn’t come to an agreement with Apple 
folks
 to standardize it.

Regardless of venue and consensus, it seems important that you'd have a spec 
that clearly outlines what you are trying to ship here, so that if and when 
other vendors would like to follow (e.g. you mentioned Firefox are interested 
in following) they would be able to.

Moreover all browsers have different sanitization behavior in the clipboard 
copy/paste methods so it will be hard to change anything there without breaking 
the legacy DataTransfer APIs that use the same sanitization algorithms.

Thanks,
Anupam

From: Philip Jägenstedt mailto:foo...@chromium.org>>
Sent: Wednesday, January 12, 2022 8:42 AM
To: Anupam Snigdha mailto:sni...@microsoft.com>>
Cc: Domenic Denicola mailto:dome...@chromium.org>>; Chris 
Harrelson mailto:chris...@chromium.org>>; Daniel Bratell 
mailto:bratel...@gmail.com>>; Yoav Weiss 
mailto:yoavwe...@chromium.org>>; blink-dev 
mailto:blink-dev@chromium.org>>; Alex Russell 
mailto:slightly...@chromium.org>>; Abhishek Rathi 
mailto:rath...@gmail.com>>; 
svo...@gmail.com 
mailto:svoi...@gmail.com>>; 
ajayra...@google.com 
mailto:ajayrahate...@google.com>>; Bo Cupp 
mailto:pc...@microsoft.com>>; 
m...@google.com 
mailto:m...@google.com>>; Joshua Bell 
mailto:jsb...@chromium.org>>; Victor Costan 
mailto:pwn...@chromium.org>>; Scott Low 
mailto:sc...@microsoft.com>>
Subject: Re: [EXTERNAL] Re: [blink-dev] Re: Intent to Ship: Pickling for Async 
Clipboard API

Hi Anupam,

Could 

Re: [blink-dev] Intent to Ship: Digital Goods API v2.0

[Rouslan Solomakhin]

> There are lots of stores, and also several browsers based on
> Chromium. Have we talked to them? Is anyone interested in
> adding support for this?

Yes, we have talked to the other browsers and stores. We have received some
questions and no objections. So far, there are no public signals that any
other browser has concrete plans to implement DGAPI.

> There are also mentions to v2.0 and v2.1.
> Which one would be shipping?

We would like to ship 2.0 to stable. The 2.1 changes

are non-breaking (only additive) and feature-detectable. These would be
coming several milestones after 2.0 ships.

> Are you expecting more changes on the API in the short term?

As with anything, it's hard to say for sure, but it is possible that 2.2
may eventually come out.

> It might be hard to implement those changes once it's shipped.

What kind of difficulties do you foresee? In my (admittedly small) past
experience, the web platform has the ability to carefully iterate on
shipped features, if the need arises.

> It looks like the spec PR hasn't been merged yet
> (https://github.com/WICG/digital-goods/pull/40).

https://wicg.github.io/digital-goods/ is the snapshot of what we would like
to ship, while the pull request at
https://github.com/WICG/digital-goods/pull/40 has been left open for a spec
mentor to review it and leave any comments that they may have. (Pull
requests on GitHub have convenient features for reviews like that.)

> I'd love to understand better the efforts to convince other browsers
> and stores about the benefits of this API.

We reached out widely during the 2021 TPAC, in the PWA Dev Sync meeting in
January of 2022, through bug trackers, and in personal communications. The
reception has been mostly neutral so far. I suspect that other members of
the ecosystem would like to see DGAPI succeed with web developers before
they invest their own resources into it, which makes sense on some level.

On Thu, Feb 3, 2022 at 6:01 AM Manuel Rego Casasnovas 
wrote:

>
>
> On 02/02/2022 16:51, Rouslan Solomakhin wrote:
> >> Rouslan, it looks to me like the API is designed to support multiple
> > stores, right?
> >> For example if Samsung decided that they wanted to support connecting
> > it up to
> >> both the Android Play Billing API (so SBrowser could provide
> > equivalent user
> >> experience to Chrome) AND to the Samsung store (so merchants could have
> >> a choice in stores, perhaps competing on terms like commission rate)
> they
> >> could do that with the current API shape, right?
> >
> > That is correct. The API shape has been generalized enough to be
> > store-agnostic and browser-agnostic. We have
> > <
> https://docs.google.com/document/d/1X2j1wKC2T4RONcUGYxGus8Dytv6s2_tVTUSkWDWPza4/edit#heading=h.chc35okxwb9
> >
> > been  pitching the
> > API to other stores and browsers as well.
>
> It'd be really nice to get some engagement from other browsers or
> stores. There are lots of stores, and also several browsers based on
> Chromium. Have we talked to them? Is anyone interested in adding support
> for this?
>
> There are also mentions to v2.0 and v2.1. Which one would be shipping?
> Are you expecting more changes on the API in the short term? It might be
> hard to implement those changes once it's shipped.
>
> On the TPAC presentation there was this plan:
> * Collect feedback from the origin trial.
> * Publish draft spec in WICG.
> * Iterate with more developer feedback.
> * Collaborate with other user agents and app stores.
> * Ship it.
>
> It looks like the spec PR hasn't been merged yet
> (https://github.com/WICG/digital-goods/pull/40), and I'd love to
> understand better the efforts to convince other browsers and stores
> about the benefits of this API.
>
> > On Wed, Feb 2, 2022 at 10:31 AM Rick Byers  > > wrote:
> >
> > +1 to Yoav's perspective here. Our job is not to force
> > interoperability but to create the conditions to make future
> > interoperability as easy as possible. We have multiple examples of
> > APIs where originally Chrome was the only interested browser, but
> > once sites started to adopt them and demonstrate the value, other
> > browsers decided they wanted to provide their users with that value
> > too. I would hate to create a condition where, for example, Brave,
> > Edge or Samsung browser felt compelled to support an API with
> > 'Chrome' in it's name once there was clear user value to supporting
> > the use case. Further, if we put Chrome in the name that could be
> > perceived as indicating that we were actively trying to create such
> > browser lock-in or otherwise create conditions for Chrome to have an
> > unfair advantage over other browsers when nothing could be further
> > from the truth.
> >
> > Rouslan, it looks to me like the API is designed to 

Re: [blink-dev] Intent to Deprecate and Remove: Support for filesystem URLs on Android media

[Frédéric Wang]

Hello,

filesystem: URLs were one of the remaining proprietary behavior when I 
was trying to unify the notions of "secure context" in Chromium [1]. I 
support a plan for unshipping it.


To elaborate a bit, a URL is potentially trustworthy if its origin is 
potentially trustworthy [2]. But Chromium determines the origin of 
filesystem: URLs the same as blob: URLs, instead of treating them as 
opaque origins per the WHATWG spec [3] [4].


So maybe that's a silly idea, but perhaps another intermediate step 
before full removal would be to stop treating filesystem: URLs as 
trustworthy if their origin is trustworthy? That would be an easy way to 
limit what web developers can do with filesystem: URLs, while still 
keeping the core support in place.


[1] https://groups.google.com/a/chromium.org/g/blink-dev/c/2fNfT6DEWJo
[2] https://w3c.github.io/webappsec-secure-contexts/#is-url-trustworthy
[3] https://url.spec.whatwg.org/#concept-url-origin
[4] https://github.com/w3c/webappsec-secure-contexts/pull/89


Le 01/02/2022 à 10:32, Mike West a écrit :
I worry that removing `filesystem:` for media elements on Android, 
while maintaining support for other platforms, will end up causing 
some developer confusion without much value for the codebase as a 
whole (since we need to maintain all the exciting bits and pieces of 
infrastructure). Are the numbers you quoted for media elements on 
those other platforms, or all element types? Perhaps we could remove 
support for media elements on all platforms if there's substantial 
benefit to doing so.


Honestly, I'd prefer that we outline a plan to fully remove 
`filesystem:` if we're not going to support it going forward (+Josh 
and +Victor). It has some pretty complicated effects on the security 
state of navigations, and while we have a reasonable plan for 
PolicyContainer integration with `blob:` URLs, we're still a ways away 
from doing the same for `filesystem:`. Is there a path towards 
deprecating and dropping support on other platforms? The large 
ChromeOS usage makes me somewhat suspicious that this is wrapped up in 
one Google property or another... have y'all done that analysis?


-mike
On Wednesday, January 26, 2022 at 7:48:54 PM UTC+1 Brianna Goldstein 
wrote:


Additionally to follow up on @Chris Harrelson
's question on usage - Chrome OS
usage is 1.38%, Mac OSX is at 0.12% and Windows is 0.05%. We
propose to only remove support for Android here.

On Tue, Jan 25, 2022 at 7:13 PM Chris Harrelson
 wrote:

Hi, could you outline the use counter values for other
platforms? Also, is there something special about Android that
leads you to want to disable only there?

On Tue, Jan 25, 2022 at 1:58 PM Brianna Goldstein
 wrote:


Primary eng (and PM) emails

brgoldst...@google.com ,
m...@chromium.com ,
jadekess...@chromium.com 


Explainer

Storage partitioning explainer




Summary

We propose to remove support for loading media via
filesystem:// URLs on Android.



Motivation

As part of our storage partitioning efforts, we will need
to update Filesystem URLs to be partitioned by StorageKey
rather than by Origin. Doing this will add complexity
since the entire current codepath on Android is not
dependent on Blink where StorageKey currently lives. On
Android only 0.001% of URLs loaded by  or
 use the filesystem:// URL scheme and we consider
this low enough usage to remove support, rather than do
the work of partitioning. Note that this removal is only
for Android. On other platforms there will be no effect
and media playback of filesystem:// URLs will continue to
work.


Blink component

Blink>Storage




Initial public proposal

None


TAG review

None


TAG review status

N/A


Interoperability and Compatibility Risk


  Interoperability risk:

The filesystem:// URL scheme was never widely adopted and
is only implemented by Chrome. Therefore there should be
no interoperability risks associated with this feature
depreciation.


  Compatibility risk:

This feature is very low usage as only 0.001% of URLs
loaded by  or  use the filesystem:// URL
scheme. Therefore the expected 

Re: [blink-dev] Intent to Ship: Digital Goods API v2.0

[Manuel Rego Casasnovas]

On 02/02/2022 16:51, Rouslan Solomakhin wrote:
>> Rouslan, it looks to me like the API is designed to support multiple
> stores, right?
>> For example if Samsung decided that they wanted to support connecting
> it up to
>> both the Android Play Billing API (so SBrowser could provide
> equivalent user
>> experience to Chrome) AND to the Samsung store (so merchants could have
>> a choice in stores, perhaps competing on terms like commission rate) they
>> could do that with the current API shape, right?
> 
> That is correct. The API shape has been generalized enough to be
> store-agnostic and browser-agnostic. We have
> 
> been  pitching the
> API to other stores and browsers as well.

It'd be really nice to get some engagement from other browsers or
stores. There are lots of stores, and also several browsers based on
Chromium. Have we talked to them? Is anyone interested in adding support
for this?

There are also mentions to v2.0 and v2.1. Which one would be shipping?
Are you expecting more changes on the API in the short term? It might be
hard to implement those changes once it's shipped.

On the TPAC presentation there was this plan:
* Collect feedback from the origin trial.
* Publish draft spec in WICG.
* Iterate with more developer feedback.
* Collaborate with other user agents and app stores.
* Ship it.

It looks like the spec PR hasn't been merged yet
(https://github.com/WICG/digital-goods/pull/40), and I'd love to
understand better the efforts to convince other browsers and stores
about the benefits of this API.

> On Wed, Feb 2, 2022 at 10:31 AM Rick Byers  > wrote:
> 
> +1 to Yoav's perspective here. Our job is not to force
> interoperability but to create the conditions to make future
> interoperability as easy as possible. We have multiple examples of
> APIs where originally Chrome was the only interested browser, but
> once sites started to adopt them and demonstrate the value, other
> browsers decided they wanted to provide their users with that value
> too. I would hate to create a condition where, for example, Brave,
> Edge or Samsung browser felt compelled to support an API with
> 'Chrome' in it's name once there was clear user value to supporting
> the use case. Further, if we put Chrome in the name that could be
> perceived as indicating that we were actively trying to create such
> browser lock-in or otherwise create conditions for Chrome to have an
> unfair advantage over other browsers when nothing could be further
> from the truth.
> 
> Rouslan, it looks to me like the API is designed to support multiple
> stores, right? For example if Samsung decided that they wanted to
> support connecting it up to both the Android Play Billing API (so
> SBrowser could provide equivalent user experience to Chrome) AND to
> the Samsung store (so merchants could have a choice in stores,
> perhaps competing on terms like commission rate) they could do that
> with the current API shape, right?
> 
> We've fought hard to get away from the webkit-prefixed and "chrome
> apps" world and we know it's not possible to know up front that an
> API will never have interoperable implementations. I think the
> downside of potentially using up a small piece of the global API
> namespace for an API that fails to achieve interoperability is much
> smaller than the downside of disincentivizing other implementations
> or burning a Chrome/Play API name into the web for what may become
> more general.

I agree this is something we want to avoid. And I understand what Yoav
and your are explaining. It makes sense to create standard APIs not
attached to a single browser, so in the future they can be adopted by
others.

I just want to have a better picture of what we're doing to convince
others to adopt this.

> At the same time, the TAG has been clear that their time is best
> spent on the APIs that are most likely to become interoperable
> standards. Dan told me at one point that it might be best if we
> didn't even both asking for TAG review that didn't have engagement
> from a 2nd browser., so I don't think we should expect them to have
> any real interest in reviewing this API. They've already marked this
> review as closed, so I don't think we should expect a response.

TAG was closed with that feedback in July:
https://github.com/w3ctag/design-reviews/issues/571

A week ago there was a comment that this was going to ship without
following that feedback, and the TAG reopened the issue. That's what I
was suggesting to give them some time to reply.

> Rego, what do you think? I'll give my LGTM3 but also happy to keep
> discussing the tradeoffs here. I really appreciate having the
>