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

[Matt Giuca]

Hi Yoav,

The API was specifically designed to allow developers to customize the
fallback, so the short answer is "whatever fallback they want".

Since the "display" Manifest member only allows for a single string, adding
a new value there would break backwards compatibility for any site that
used the new value. That is why we do not allow "tabbed" and other new
display modes in that member; they can only be used in the new
"display_override" member which is a list of display modes representing a
developer-supplied fallback chain, with the final fallback being the value
of the old "display" member.

So developers can generally choose between two configurations:

   1. "display_override": ["tabbed"], "display": "standalone"
   2. "display_override": ["tabbed"], "display": "browser"

If they choose #1, non-supported platforms will fall back to a standalone
non-tabbed window (feeling like an app but not having a tabbed experience).
If they choose #2, non-supported platforms will fall back to not having a
separate window and just opening the content in the browser (giving the
user a tabbed experience but not feeling like an app).

We would recommend that developers fall back to whatever they are already
using. That way, tabbed mode is an additive experience (currently only on
ChromeOS but automatically upgrading to that experience on any platform
that supports it in the future), with a graceful degradation to the status
quo.

Therefore, we don't think cross platform support for this feature is
necessary, though of course it has been designed for this as a future
possibility. Also there is nothing ChromeOS-specific about this design, as
Marijn pointed out, it just hasn't been prioritized by the engineering team
outside of ChromeOS.

Regards

Matt

On Tue, 7 May 2024 at 19:24, Yoav Weiss (@Shopify) 
wrote:

> Can you elaborate on the cross-platform story here? What kind of fallback
> do we expect developers to use in non-supporting platforms?
>
> On Tue, May 7, 2024 at 12:34 AM Marijn Kruisselbrink 
> wrote:
>
>> I don't think there are major technical reasons, no. With some rough
>> edges the flagged implementation should more or less work on other
>> desktop platforms as well. My understanding is that this is largely a
>> product choice and a choice not to prioritize the remaining engineering
>> needed to clean up the rough edges on other desktop platforms.
>>
>> On Mon, May 6, 2024 at 3:29 PM Daniel Herr 
>> wrote:
>>
>>> May I ask why? I've tried out the flagged implementation on Chrome OS,
>>> and I think it is a pretty nice UI paradigm. I don't see any technical
>>> reason it shouldn't be available on other platforms.
>>>
>>> On Monday, May 6, 2024 at 10:30:58 AM UTC-4 Brett Wilson wrote:
>>>
 On Mon, May 6, 2024 at 3:02 AM Yoav Weiss (@Shopify) <
 yoav...@chromium.org> wrote:

>
>
> On Fri, May 3, 2024 at 7:28 PM Brett Wilson 
> wrote:
>
>> Contact emailsbre...@chromium.org, alanc...@chromium.org,
>> mgi...@chromium.org, loub...@google.com
>>
>> Explainer
>> https://github.com/WICG/manifest-incubations/blob/gh-pages/tabbed-mode-explainer.md
>>
>> Specificationhttps://wicg.github.io/manifest-incubations/#dfn-tabbed
>>
>> Summary
>>
>> Allow web app windows to have a tab strip. This adds a new display
>> mode "tabbed" and a new manifest field to allow customizations to the tab
>> strip.
>>
>>
>> Blink componentBlink>AppManifest
>> 
>>
>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/841
>>
>> TAG review statusIssues addressed
>>
>> Chromium Trial NameWebAppTabStrip
>>
>> Link to origin trial feedback summary
>> https://github.com/WICG/manifest-incubations/issues
>>
>> Origin Trial documentation link
>> https://github.com/WICG/manifest-incubations/blob/gh-pages/tabbed-mode-explainer.md
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>>
>>
>> *Gecko*: Defer (
>> https://github.com/mozilla/standards-positions/issues/811)
>>
>> *WebKit*: No signal (
>> https://github.com/WebKit/standards-positions/issues/195)
>>
>> *Web developers*: Positive (
>> https://github.com/w3c/manifest/issues/737)
>>
>> *Other signals*:
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such
>> that it has potentially high risk for Android WebView-based applications?
>>
>> N/A
>>
>>
>> Debuggability
>>
>> chrome://web-app-internals can be used for debugging, and the new
>> manifest field could also be added to the DevTools Application pane.
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows,
>> Mac, Linux, ChromeOS, Android, and Android WebView)?No
>>
>> The origin tr

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

['Tommy Steimel' via blink-dev]

Contact emailsstei...@chromium.org, liber...@chromium.org

ExplainerNone

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

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

Summary

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


Blink componentBlink>Media>PictureInPicture


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

TAG review statusPending

Risks


Interoperability and Compatibility

None


*Gecko*: No signal (
https://github.com/mozilla/standards-positions/issues/670#issuecomment-2096824367
)

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

*Web developers*: No signals

*Other signals*:

Ergonomics

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


Activation

N/A


Security

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


WebView application risks

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

N/A


Debuggability

N/A


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

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


Is this feature fully tested by web-platform-tests

?Yes

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


Flag name on chrome://flagsdocument-picture-in-picture-user-activation

Finch feature nameDocumentPictureInPictureUserActivation

Requires code in //chrome?False

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

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

Estimated milestones
Shipping on desktop 126

Anticipated spec changes

Open questions about a feature may be a source of future web compat or
interop issues. Please list open issues (e.g. links to known github issues
in the project for the feature specification) whose resolution may
introduce web compat/interop risk (e.g., changing to naming or structure of
the API in a non-backward-compatible way).
N/A

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

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAE-AwApczWrtoZNMqtAJx-%2BNAxVF9Kqim2h1HBrAD3ukXTKgWA%40mail.gmail.com

This intent message was generated by Chrome Platform Status
.

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

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

['Sahir Vellani' via blink-dev]

Hi all, re-opening this thread. The feature has been re-implemented based 
on the PEWG feedback and guidance. Here is a quick summary of changes -
- The PR against spec  has 
received lots of fruitful discussion and feedback, and is now in a stable 
state. We do not anticipate any further breaking changes to the uniqueId 
API.
- PointerEvent.deviceId has been changed to 
PointerEvent.deviceProperties.uniqueId. There is no longer a reserved id 
for the mouse pointer. Invalid id is 0 instead of -1. The discussion and 
reasoning behind all changes can be found in the spec PR.
- WPT tests have been implemented for this feature.
- The feature has been verified by our partners via Origin Trial

Any oppositions to this being shipped in Chromium?
On Monday, February 12, 2024 at 6:53:30 AM UTC-8 fla...@chromium.org wrote:

> I think deviceProperties is reasonable. The other question was when 
> deviceId would be populated? E.g. should touches on the same touchscreen 
> device have the same deviceId or should we only have a deviceId when we can 
> uniquely identify the particular pointer? I suspect maybe the latter since 
> otherwise you couldn't infer uniqueness from its existence.
>
> Could you comment on the pointerevents issue 
>  so that the context is 
> there for the next meeting? I'll request that it be discussed again.
>
> On Thu, Feb 1, 2024 at 4:31 PM 'Sahir Vellani' via blink-dev <
> blin...@chromium.org> wrote:
>
>> Thanks for the update Robert! That makes sense. 
>>
>> What about deviceProperties? That would place the emphasis on the device 
>> generating the pointer event; with "properties" being generic enough to 
>> include different supported functions of the device. So we would have 
>> something like 
>> PointerEvent.deviceProperties.deviceId/PointerEvent.deviceProperties.preferredInkingColor
>>  
>> etc.
>>
>> Would you be able to clarify the next steps once the structure name has 
>> been agreed upon? I believe we'll need to update the explainer, spec PR and 
>> change the chromium implementation. Anything else? 
>>
>
> This sounds good.
>
> On Thursday, February 1, 2024 at 12:33:46 PM UTC-8 fla...@chromium.org 
>> wrote:
>>
>>> We just discussed this yesterday where the consensus was that we thought 
>>> it would be pragmatic to put this new device specific identifier into a 
>>> common structure on the pointer event where other device specific 
>>> customizations could later be added (e.g. those from the pen 
>>> customizations proposal 
>>> ). This avoids needing 
>>> to have new properties on the pointer event for each device specific 
>>> customization attribute added.
>>>
>>> Another question that came up was how universal this customization was, 
>>> i.e. whether there would be support for this on other platforms.
>>>
>>> @Sahir Vellani would you be able to suggest what you think the best 
>>> structure name / property name for pointer specific identifier properties 
>>> might be?
>>>
>>> I do agree with @Rick Byers that this is likely a niche API which we'll 
>>> likely be able to change, I'm just trying to get ahead of breaking changes 
>>> early.
>>>
>>> On Wed, Jan 31, 2024 at 11:33 AM Yoav Weiss (@Shopify) <
>>> yoav...@chromium.org> wrote:
>>>
 Thanks for chiming in, Robert!

 Sahir - can you let us know once the PEWG has discussed this and you 
 feel this is good to go?

 On Tuesday, January 23, 2024 at 8:26:32 PM UTC+1 
 sahir@microsoft.com wrote:

> Thanks Rick and Robert! 
>
> Rick, I agree that it would be relatively easy to change/deprecate 
> deviceId. There are not too many devices at the moment that support 
> multiple pens, and not many web apps either. I think the cost to the 
> websites of not having Chrome support this for the foreseeable future is 
> greater than changing where the deviceId gets read from. The Pen 
> Customizations api looks quite cool, although deviceId is more generic.
>
> Robert, I'm happy to wait a week or two more for the PEWG to discuss 
> this further. Thanks for putting deviceId in the agenda, and of course we 
> can rework this if a more appropriate alternative is proposed. :)
>
> On Tuesday, January 23, 2024 at 11:01:05 AM UTC-8 fla...@chromium.org 
> wrote:
>
> On Tue, Jan 23, 2024 at 1:00 PM Robert Flack  
> wrote:
>
> FWIW, in the PEWG call 
>  last 
> week there was some question of how this relates to the pen 
> customizations proposal 
> . I suppose the 
> general question is whether this should be an additional part of some 
> hardware specific device customization in 
> pointerEvent.penCustomizationsDetails. I think there is a risk of 
>

Re: [blink-dev] Intent to Experiment: FedCM as a trust signal for the Storage Access API

[Mike Taylor]

LGTM to experiment from 126 to 127 inclusive.

On 5/7/24 10:52 AM, Chris Fredrickson wrote:


Contact emails

johann...@chromium.org, cfred...@chromium.org, y...@chromium.org


Explainer

https://github.com/explainers-by-googlers/storage-access-for-fedcm 




Specification

None (TBD)


Summary

Reconciles the FedCM and Storage Access APIs by making a prior FedCM 
grant a valid reason to automatically approve a storage access request.



When a user grants permission for using their identity with a 3rd 
party Identity Provider (IdP) on a Relying Party (RP), many IdPs 
require third-party cookies to function correctly and securely. This 
proposal aims to satisfy that requirement in a private and secure 
manner by updating the Storage Access API (SAA) permission checks to 
not only accept the permission grant that is given by a storage access 
prompt, but also the permission grant that is given by a FedCM prompt.



A key property of this mechanism is limiting the grant to cases 
explicitly allowed by the RP via the FedCM permissions policy, 
enforcing a per-frame control for the RP and preventing passive 
surveillance by the IdP beyond the capabilities that FedCM already 
grants, as outlined in the Privacy Considerations 
.




Blink component

Blink>StorageAccessAPI


TAG review

None


TAG review status

N/A


Risks



Interoperability and Compatibility

None




Gecko: No public signals, positive initial signals 
. 
We will request a formal position.



WebKit: No signal. We will request a formal position.


Web developers: Positive 


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?


N/A, not shipping on Android WebView.


Goals for experimentation

Evaluate the implementation, and the usability of the feature to 
ensure it adequately solves the problem.



Ongoing technical constraints

None


Debuggability

None


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


No. It will not be supported in Android WebView.


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

No. The implementation is primarily in permissions code in //chrome, 
which cannot be tested in WPTs since WPTs use a fake permission 
manager 
in 
Chromium.



Flag name on chrome://flags

#fedcm-with-storage-access-api


Finch feature name

FedCmWithStorageAccessAPI


Non-finch justification

None


Requires code in //chrome?

True


Estimated milestones

M126 through M127 (inclusive).



Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5116478702747648 




Links to previous Intent discussions

Intent to prototype: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAD_OO4iogs7O60r0YcVnDB5aCvs9WUYjWFcuHqcFi5bXLRBOig%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/9a75fe74-ca55-4ddc-93d7-120adfdee49en%40chromium.org 
.


--
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e4cfab89-5510-4ce8-84f7-b7c4bbe071da%40chromium.org.

[blink-dev] Intent to Experiment: FedCM as a trust signal for the Storage Access API

[Chris Fredrickson]

Contact emails

johann...@chromium.org, cfred...@chromium.org, y...@chromium.org

Explainer

https://github.com/explainers-by-googlers/storage-access-for-fedcm

Specification

None (TBD)

Summary

Reconciles the FedCM and Storage Access APIs by making a prior FedCM grant 
a valid reason to automatically approve a storage access request.

When a user grants permission for using their identity with a 3rd party 
Identity Provider (IdP) on a Relying Party (RP), many IdPs require 
third-party cookies to function correctly and securely. This proposal aims 
to satisfy that requirement in a private and secure manner by updating the 
Storage Access API (SAA) permission checks to not only accept the 
permission grant that is given by a storage access prompt, but also the 
permission grant that is given by a FedCM prompt.

A key property of this mechanism is limiting the grant to cases explicitly 
allowed by the RP via the FedCM permissions policy, enforcing a per-frame 
control for the RP and preventing passive surveillance by the IdP beyond 
the capabilities that FedCM already grants, as outlined in the Privacy 
Considerations 

.


Blink component

Blink>StorageAccessAPI

TAG review

None

TAG review status

N/A

Risks


Interoperability and Compatibility

None



Gecko: No public signals, positive initial signals 
.
 
We will request a formal position.

WebKit: No signal. We will request a formal position.

Web developers: Positive 

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?

N/A, not shipping on Android WebView.

Goals for experimentation

Evaluate the implementation, and the usability of the feature to ensure it 
adequately solves the problem.

Ongoing technical constraints

None

Debuggability

None

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

No. It will not be supported in Android WebView.

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

No. The implementation is primarily in permissions code in //chrome, which 
cannot be tested in WPTs since WPTs use a fake permission manager 

 
in Chromium.

Flag name on chrome://flags

#fedcm-with-storage-access-api

Finch feature name

FedCmWithStorageAccessAPI

Non-finch justification

None

Requires code in //chrome?

True

Estimated milestones

M126 through M127 (inclusive).


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5116478702747648

Links to previous Intent discussions

Intent to prototype: 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAD_OO4iogs7O60r0YcVnDB5aCvs9WUYjWFcuHqcFi5bXLRBOig%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/9a75fe74-ca55-4ddc-93d7-120adfdee49en%40chromium.org.

[blink-dev] Ops shown in SKIA Debugger not same as PaintOps captured via Chromium

[Steven Whelan]

Hi
For the same webpage, the ops listed via SKIA Debugger are different from 
the List on PaintOps that I have captured from Chromium.

Example
Skia Debugger shows *drawPaint *operation.
*I assume drawPaint = kDrawPaint/ DrawPaintOp. *
But I cannot see this operation in the PaintOps list. similarly, Many 
operations in PaintOp list are not shown in SKIA Debugger.

Please guide

-- 
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/95f5eb3a-ec24-4b23-bcd9-bbb0616d4d63n%40chromium.org.

[blink-dev] On running Chromium - This App can't run on your PC

[Steven Whelan]

Hi 
I am working on Chromium open source. For debugging purposes, I put alerts 
and rebuild chromium on a daily basis.
However suddenly, I am getting the above mentioned error - "This App can't 
run on your PC"
I undid all the changes, but it did not get resolved.
Does this mean, I will have to build Chromium again from scratch that takes 
5-6 hours?

Thanks

-- 
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/16cf047b-14aa-4b8a-a75b-7906b97149e9n%40chromium.org.

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

[Yoav Weiss (@Shopify)]

Can you elaborate on the cross-platform story here? What kind of fallback
do we expect developers to use in non-supporting platforms?

On Tue, May 7, 2024 at 12:34 AM Marijn Kruisselbrink 
wrote:

> I don't think there are major technical reasons, no. With some rough edges
> the flagged implementation should more or less work on other
> desktop platforms as well. My understanding is that this is largely a
> product choice and a choice not to prioritize the remaining engineering
> needed to clean up the rough edges on other desktop platforms.
>
> On Mon, May 6, 2024 at 3:29 PM Daniel Herr 
> wrote:
>
>> May I ask why? I've tried out the flagged implementation on Chrome OS,
>> and I think it is a pretty nice UI paradigm. I don't see any technical
>> reason it shouldn't be available on other platforms.
>>
>> On Monday, May 6, 2024 at 10:30:58 AM UTC-4 Brett Wilson wrote:
>>
>>> On Mon, May 6, 2024 at 3:02 AM Yoav Weiss (@Shopify) <
>>> yoav...@chromium.org> wrote:
>>>


 On Fri, May 3, 2024 at 7:28 PM Brett Wilson 
 wrote:

> Contact emailsbre...@chromium.org, alanc...@chromium.org,
> mgi...@chromium.org, loub...@google.com
>
> Explainer
> https://github.com/WICG/manifest-incubations/blob/gh-pages/tabbed-mode-explainer.md
>
> Specificationhttps://wicg.github.io/manifest-incubations/#dfn-tabbed
>
> Summary
>
> Allow web app windows to have a tab strip. This adds a new display
> mode "tabbed" and a new manifest field to allow customizations to the tab
> strip.
>
>
> Blink componentBlink>AppManifest
> 
>
> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/841
>
> TAG review statusIssues addressed
>
> Chromium Trial NameWebAppTabStrip
>
> Link to origin trial feedback summary
> https://github.com/WICG/manifest-incubations/issues
>
> Origin Trial documentation link
> https://github.com/WICG/manifest-incubations/blob/gh-pages/tabbed-mode-explainer.md
>
> Risks
>
>
> Interoperability and Compatibility
>
>
>
> *Gecko*: Defer (
> https://github.com/mozilla/standards-positions/issues/811)
>
> *WebKit*: No signal (
> https://github.com/WebKit/standards-positions/issues/195)
>
> *Web developers*: Positive (https://github.com/w3c/manifest/issues/737
> )
>
> *Other signals*:
>
> WebView application risks
>
> Does this intent deprecate or change behavior of existing APIs, such
> that it has potentially high risk for Android WebView-based applications?
>
> N/A
>
>
> Debuggability
>
> chrome://web-app-internals can be used for debugging, and the new
> manifest field could also be added to the DevTools Application pane.
>
>
> Will this feature be supported on all six Blink platforms (Windows,
> Mac, Linux, ChromeOS, Android, and Android WebView)?No
>
> The origin trial is available on ChromeOS only. Support for other
> desktop platforms is planned.
>
>
> Is this feature fully tested by web-platform-tests
> 
> ?Yes
>
>
> https://github.com/web-platform-tests/wpt/tree/master/appmanifest/display-override-member
>
>
> Flag name on chrome://flags
> chrome://flags/#enable-desktop-pwas-tab-strip
>
> Finch feature nameDesktopPWAsTabStrip
>
> Requires code in //chrome?True
>
> Tracking bughttps://issuetracker.google.com/issues/40598974
>
> Launch bughttps://launch.corp.google.com/launch/4253814
>
> MeasurementLaunch.WebAppDisplayMode: Tabbed
>
> Availability expectationFeature is available only on
> Chrome-on-ChromeOS for the foreseeable future.
>

 This seems a bit contradictory with "Support for other desktop
 platforms is planned" above. Are there plans for support beyond CrOS?

>
> 


>>> Sorry, the first part was a mistake. Chrome team has requested this not
>>> be on other platforms now.
>>>
>>> Brett
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/670da4b2-f0f9-4774-96a9-5cd5f96d168cn%40chromium.org
>> 
>> .
>>
>

-- 
You received this message