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

[Matt Giuca]

Yes it is ChromeOS only at the moment.

The "Chrome 126" just means it's implemented as part of the Chrome browser
(which runs in ChromeOS).

On Fri, 14 Jun 2024 at 16:19, Jaime  wrote:

> Hi everyone. I see in Tabbed web apps - Chrome Platform Status
> (chromestatus.com) <https://chromestatus.com/feature/5128143454076928> that
> it says that it is shipping in Chrome 126, but I understood that it was
> shipping first only in ChromeOS. Are there any updates for Chrome / Edge
> in Windows and Mac? This feature is fantastic for web apps and can't wait
> to use it. Thanks!
>
> On Thursday, May 16, 2024 at 12:08:52 PM UTC+7 Brett Wilson wrote:
>
>> To follow up, there's a nice shout out at Google I/O about this feature
>> and also mentions that Figma is trying it:
>>
>> https://youtu.be/KFeuEMAaKfM?si=pr71c4hfxhI5RbT0=1039
>>
>> On Sun, May 12, 2024 at 6:08 PM Matt Giuca  wrote:
>>
>>> Thanks everyone. This is now enabled on ToT in 126.
>>>
>>> On Fri, 10 May 2024 at 17:59, TAMURA, Kent  wrote:
>>>
>>>> LGTM3.
>>>>
>>>>
>>>> On Fri, May 10, 2024 at 2:41 AM Mike Taylor 
>>>> wrote:
>>>>
>>>>> LGTM2
>>>>> On 5/9/24 10:48 AM, Chris Harrelson wrote:
>>>>>
>>>>> Thanks for these clarifications.
>>>>>
>>>>> LGTM1
>>>>>
>>>>> On Wed, May 8, 2024 at 6:05 PM Daniel Murphy 
>>>>> wrote:
>>>>>
>>>>>> We don't have an objection to this feature existing - it's actually
>>>>>> currently in our backlog. But it is very low in our priority list. While 
>>>>>> we
>>>>>> can review patches, we will not be able to dedicate resources for
>>>>>> consultation or maintenance.
>>>>>>
>>>>>> On Wed, May 8, 2024 at 9:19 AM Brett Wilson 
>>>>>> wrote:
>>>>>>
>>>>>>> On Wed, May 8, 2024 at 8:39 AM Alex Russell 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I'm happy for this to be CrOS first, but would like to unpack
>>>>>>>> Brett's statement above a bit. If we (MSFT) were to polish this up for
>>>>>>>> Windows, would patches for that be accepted?
>>>>>>>>
>>>>>>>
>>>>>>> I can't speak for the browser team. But my current understanding is
>>>>>>> that the browser team likes this in principle but doesn't prioritize it
>>>>>>> high enough to work on it right now (this is a correction from my 
>>>>>>> previous
>>>>>>> assertion). So I'm pretty sure patches enabling this for other platforms
>>>>>>> would be accepted.
>>>>>>>
>>>>>>> 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+...@chromium.org.
>>>>>>> To view this discussion on the web visit
>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABiGVV-Zeyv3Rez%2BPQ%2B%2BfW4ihpRCwnnGN2HNxOyXTA7_uWehzw%40mail.gmail.com
>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABiGVV-Zeyv3Rez%2BPQ%2B%2BfW4ihpRCwnnGN2HNxOyXTA7_uWehzw%40mail.gmail.com?utm_medium=email_source=footer>
>>>>>>> .
>>>>>>>
>>>>>> --
>>>>>> 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%2B4qT32O-zoM4tarHQvoHkmYt%2B%3Dc5iOiPdkueMk%2BhUe7mkYU%2BA%40mail.gmail.com
>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2B4qT32O-zoM4tarHQvoHkmYt%2B%3Dc5iOiPdkueMk%2BhUe7mkYU%2BA%40mail.gmail.com?utm_medium=email_source=footer>
>>>>>> .
>>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>

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

[Matt Giuca]

Thanks everyone. This is now enabled on ToT in 126.

On Fri, 10 May 2024 at 17:59, TAMURA, Kent  wrote:

> LGTM3.
>
>
> On Fri, May 10, 2024 at 2:41 AM Mike Taylor 
> wrote:
>
>> LGTM2
>> On 5/9/24 10:48 AM, Chris Harrelson wrote:
>>
>> Thanks for these clarifications.
>>
>> LGTM1
>>
>> On Wed, May 8, 2024 at 6:05 PM Daniel Murphy  wrote:
>>
>>> We don't have an objection to this feature existing - it's actually
>>> currently in our backlog. But it is very low in our priority list. While we
>>> can review patches, we will not be able to dedicate resources for
>>> consultation or maintenance.
>>>
>>> On Wed, May 8, 2024 at 9:19 AM Brett Wilson  wrote:
>>>
 On Wed, May 8, 2024 at 8:39 AM Alex Russell 
 wrote:

> I'm happy for this to be CrOS first, but would like to unpack Brett's
> statement above a bit. If we (MSFT) were to polish this up for Windows,
> would patches for that be accepted?
>

 I can't speak for the browser team. But my current understanding is
 that the browser team likes this in principle but doesn't prioritize it
 high enough to work on it right now (this is a correction from my previous
 assertion). So I'm pretty sure patches enabling this for other platforms
 would be accepted.

 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/CABiGVV-Zeyv3Rez%2BPQ%2B%2BfW4ihpRCwnnGN2HNxOyXTA7_uWehzw%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/CA%2B4qT32O-zoM4tarHQvoHkmYt%2B%3Dc5iOiPdkueMk%2BhUe7mkYU%2BA%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/CAOMQ%2Bw_QmtkQeDUW%2BEbWtQC4ghvpHFk-Uf65YqYjPMjEQEwwCg%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/201d6c2d-be84-4d6b-9c4b-b1c9f89b0bf8%40chromium.org
>> 
>> .
>>
>
>
> --
> TAMURA Kent
> Software Engineer, Google
>
>
>

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

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 

Re: [blink-dev] Intent to Continue Experimenting: Tabbed Web Apps

[Matt Giuca]

The original trial was from 118 to 123, inclusive.

We want to extend it so it continues running from 124 to 126, inclusive.

On Fri, 8 Mar 2024 at 16:52, Domenic Denicola  wrote:

> For what milestones do you want to extend the experiment for?
>
> On Thu, Mar 7, 2024 at 3:39 PM Matt Giuca  wrote:
>
>> Contact emailsloubr...@google.com, glen...@chromium.org
>> , mgi...@chromium.org, bre...@chromium.org
>>
>> Explainer
>> https://github.com/WICG/manifest-incubations/blob/gh-pages/tabbed-mode-explainer.md
>>
>> Specificationhttps://github.com/WICG/manifest-incubations/pull/95 (draft)
>>
>> 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.
>>
>> Following a 6-milestone origin trial, we would like to continue
>> experimenting as the feature team is not ready to commit to shipping, and
>> gathered very little data from the initial experiment (as partners we have
>> lined up have not yet started their experiment).
>>
>> Per the Blink policy, we have made substantial progress in these five
>> areas:
>>
>>- Draft spec: https://github.com/WICG/manifest-incubations/pull/95
>>- TAG review: https://github.com/w3ctag/design-reviews/issues/841
>>(closed with "unsatisfied"; I have sent a follow-up comment).
>>- Signals requests:
>>   - WebKit: https://github.com/WebKit/standards-positions/issues/195
>>   (ignored)
>>   - Mozilla:
>>   https://github.com/mozilla/standards-positions/issues/811 (closed
>>   as not interested in any of "these sorts of features")
>>- Outreach for feedback from spec community:
>>https://developer.chrome.com/docs/capabilities/tabbed-application-mode
>>- WPT tests:
>>
>> https://github.com/web-platform-tests/wpt/blob/master/appmanifest/display-override-member/display-override-member-media-feature-tabbed-manual.tentative.html
>>
>> Blink componentBlink>AppManifest
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EAppManifest>
>>
>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/841
>>
>> TAG review statusClosed ("Unsatisfied")
>>
>> Chromium Trial NameWebAppTabStrip
>>
>> Origin trial feedback summary
>> Only a small number of signups, most look like individuals wanting to
>> experiment. A handful of small PWAs are using it. A few large sites signed
>> up for the trial but do not appear to be using it.
>>
>> That said, we think this is a useful feature and want to keep exploring
>> possible customers of the API.
>>
>> I was unable to see any qualitative feedback from registrants.
>>
>> Origin Trial documentation link
>> https://developer.chrome.com/docs/capabilities/tabbed-application-mode
>>
>> 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
>>
>>
>>
>> Goals for experimentation
>>
>> Roll out one major client and get developer and user feedback.
>>
>> Ongoing technical constraints
>>
>> Reuses browser tab strip code, adding further dependency between the
>> browser tab strip and PWA windows.
>>
>> 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 but low priority.
>>
>>
>> Is this feature fully tested by web-platform-tests
>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>> ?Partial (more coming)
>>
>> Flag name on chrome://flagschrome://flags/#enable-desktop-pwas-tab-strip
>>
>> Finch feature nam

[blink-dev] Intent to Continue Experimenting: Tabbed Web Apps

[Matt Giuca]

Contact emailsloubr...@google.com, glen...@chromium.org
, mgi...@chromium.org, bre...@chromium.org

Explainer
https://github.com/WICG/manifest-incubations/blob/gh-pages/tabbed-mode-explainer.md

Specificationhttps://github.com/WICG/manifest-incubations/pull/95 (draft)

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.

Following a 6-milestone origin trial, we would like to continue
experimenting as the feature team is not ready to commit to shipping, and
gathered very little data from the initial experiment (as partners we have
lined up have not yet started their experiment).

Per the Blink policy, we have made substantial progress in these five areas:

   - Draft spec: https://github.com/WICG/manifest-incubations/pull/95
   - TAG review: https://github.com/w3ctag/design-reviews/issues/841
   (closed with "unsatisfied"; I have sent a follow-up comment).
   - Signals requests:
  - WebKit: https://github.com/WebKit/standards-positions/issues/195
  (ignored)
  - Mozilla: https://github.com/mozilla/standards-positions/issues/811
  (closed as not interested in any of "these sorts of features")
   - Outreach for feedback from spec community:
   https://developer.chrome.com/docs/capabilities/tabbed-application-mode
   - WPT tests:
   
https://github.com/web-platform-tests/wpt/blob/master/appmanifest/display-override-member/display-override-member-media-feature-tabbed-manual.tentative.html

Blink componentBlink>AppManifest


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

TAG review statusClosed ("Unsatisfied")

Chromium Trial NameWebAppTabStrip

Origin trial feedback summary
Only a small number of signups, most look like individuals wanting to
experiment. A handful of small PWAs are using it. A few large sites signed
up for the trial but do not appear to be using it.

That said, we think this is a useful feature and want to keep exploring
possible customers of the API.

I was unable to see any qualitative feedback from registrants.

Origin Trial documentation link
https://developer.chrome.com/docs/capabilities/tabbed-application-mode

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



Goals for experimentation

Roll out one major client and get developer and user feedback.

Ongoing technical constraints

Reuses browser tab strip code, adding further dependency between the
browser tab strip and PWA windows.

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 but low priority.


Is this feature fully tested by web-platform-tests

?Partial (more coming)

Flag name on chrome://flagschrome://flags/#enable-desktop-pwas-tab-strip

Finch feature name

Non-finch justificationNone

Requires code in //chrome?True

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

Launch bughttps://launch.corp.google.com/launch/4253814

Estimated milestones
OriginTrial desktop last 126
OriginTrial desktop first 118

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

Links to previous Intent discussionsIntent to prototype:
https://groups.google.com/a/chromium.org/g/blink-dev/c/IvfIkjvQYuY/m/cixwOyEeAAAJ
Intent to Experiment:
https://groups.google.com/a/chromium.org/g/blink-dev/c/m16m2TEq-NM/m/0Bc10numCgAJ


This intent message was generated by Chrome Platform Status
 and edited by hand.

-- 
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/CAHqYdcawL46igjAk27MDhEE2-F%3DgKOHjdqXqPS4%3DtD_M6gNqmA%40mail.gmail.com.

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

[Matt Giuca]

@Šime: Yes, the feature as currently implemented is exposed as a media
query: "(display-mode: tabbed)" works.

We flagged additionally the need to be able to detect whether you're in the
special home tab. I'm not sure how you do that (whether it's a media query
or some other way) and it isn't mentioned in the explainer
.
Perhaps Louise can explain (out until next week) if there is a way to do
it. However, I checked the basic detection of "am I in tabbed mode" works
with a media query.

On Mon, 24 Jul 2023 at 20:25, Thomas Steiner  wrote:

> On Mon, Jul 24, 2023 at 01:04 Šime Vidas  wrote:
>
>> Is it available in CSS media queries?
>>
>> @media (display-mode: tabbed) { ... }
>>
>
> I have opened https://github.com/w3c/manifest/issues/952 where the same
> request is made for all overrides.
>
>
>
>> On Wednesday, July 19, 2023 at 9:50:44 AM UTC+2 yoav...@chromium.org
>> wrote:
>>
>>> LGTM to experiment M116-122 (inclusive)
>>>
>>> On Wed, Jul 19, 2023 at 8:14 AM 'Louise Brett' via blink-dev <
>>> blin...@chromium.org> wrote:
>>>
 Contact emailsloub...@google.com, alanc...@chromium.org,
 gle...@chromium.org, mgi...@chromium.org

>>>

 Explainer
 https://github.com/WICG/manifest-incubations/blob/gh-pages/tabbed-mode-explainer.md

 SpecificationNone

 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 statusPending

 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. This feature is not supported on WebView so we will fallback to a
 supported display mode.



 Goals for experimentation

 Gather feedback on the API design.

 Ongoing technical constraints



 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, Chrome OS, Android, and Android WebView)?No. Initially
 this will only be available on ChromeOS, but will be expanded to other
 desktop platforms in the future.


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

 Flag name on chrome://flags
 chrome://flags/#enable-desktop-pwas-tab-strip
 chrome://flags/#enable-desktop-pwas-tab-strip-customizations

 Finch feature nameNone

 Non-finch justificationNone

 Requires code in //chrome?True

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

 Launch bughttps://launch.corp.google.com/launch/4253814

 Estimated milestones

 Requesting to run an origin trial from 117-122 (inclusive).


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

 Links to previous Intent discussionsIntent to prototype:
 https://groups.google.com/a/chromium.org/g/blink-dev/c/IvfIkjvQYuY/m/cixwOyEeAAAJ

 This intent message was generated by Chrome Platform Status
 .

>>> --
 You received this message because you are subscribed to the Google
 Groups "blink-dev" group.

>>> To unsubscribe from this group and stop receiving emails from it, send
 an email to blink-dev+...@chromium.org.
 To view this discussion on the web visit
 https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABeVxY3HJP8hqiNkF186unEVXu6TquM0JuBpw_K5sH6uhxaOeg%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 

Re: [blink-dev] Intent to Ship: Web app launch handler

[Matt Giuca]

Hey Yoav,

On Wed, 19 Oct 2022 at 23:52, Yoav Weiss  wrote:

> Hey! Thanks for pushing this :)
>
> On Tue, Oct 18, 2022 at 8:42 AM Alan Cutter 
> wrote:
>
>> Contact emailsalancut...@chromium.org, mgi...@chromium.org
>>
>> Explainerhttps://github.com/WICG/sw-launch/blob/main/launch_handler.md
>>
>> Specificationhttps://wicg.github.io/sw-launch
>>
>
> I went over the spec and filed a few issues. None of them seems blocking
> (as in, they won't change the API shape), but they'd help us achieve an
> interoperable specification.
>
> Would it be possible for y'all to go over the issues list, close the ones
> that are no longer relevant, and then label ones that may contain any
> future compat risk, if any? (That is, issues that may change the API shape
> once resolved)
>
> Aside: should the repo be renamed to "web-app-launch" or something similar?
>

It probably should!

Historical context: This repo has been around for five years and has been
used, at various times, for at least three related proposals (each
superseding the last), the first of which was a Service-Worker-exclusive
"launch" event, then rebranding as "declarative link capturing" for a
purely declarative launch system, and finally to a more generic "launch
handler" allowing both a declarative or programmatic option, in either a
foreground page or service worker.

The name "sw-launch" isn't appropriate any more, but on the other hand
there are probably hundreds of incoming links to the sw-launch repo that
would break if we renamed it. Have you done a similar scale of rename
before in a WICG repo and would you recommend it again?

Since WICG is supposed to be a temporary staging area anyway, my preference
would be to update as many things as possible to use the new name, which
don't break the URL (e.g. change the "about" field in GitHub), but not
rename the repo, and give it an appropriate name if/when it transitions out
of WICG and needs a new URL anyway. Does that sound reasonable?


>
>>
>> Summary
>>
>> Add a "launch_handler" web app manifest member that enables web apps to
>> customize their launch behavior across all types of app launch triggers.
>> Example usage: { "name": "Example app", "start_url": "/index.html",
>> "launch_handler": { "client_mode": "navigate-existing" } } This will cause
>> all launches of the Example app to focus an existing app window and
>> navigate it (if it exists) instead of always opening a new app window.
>>
>>
>> Blink componentBlink>AppManifest
>> 
>>
>> Search tagsweb app ,
>> pwa , link capturing
>> , link handling
>> , launch
>> 
>>
>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/683
>>
>> TAG review statusIssues addressed
>>
>> Link to origin trial feedback summary
>> https://docs.google.com/document/d/1t60YeQ-d-FSr9i91jvylW6sA7_R4jDnX1G4_PDfssYE/edit
>>
>> Risks
>>
>>
>> Interoperability and Compatibility
>>
>>
>>
>> *Gecko*: No signal (
>> https://github.com/mozilla/standards-positions/issues/567)
>>
>> *WebKit*: No signal (
>> https://lists.webkit.org/pipermail/webkit-dev/2022-May/032243.html)
>>
>> *Web developers*: Strongly positive. Feedback from sites using this API
>> has been strongly in favor of keeping the functionality.
>>
>> *Other signals*:
>>
>> WebView application risks
>>
>> Does this intent deprecate or change behavior of existing APIs, such that
>> it has potentially high risk for Android WebView-based applications?
>>
>> None. This feature only affects installed web apps which run in a regular
>> browser environment rather than a WebView.
>>
>>
>> Debuggability
>>
>> Adding the field to DevTools is in progress
>> .
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?No, desktop only.
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?No, this requires browser_tests
>> 
>>  as
>> it involves managing windows.
>> Have raised an issue
>>  with
>> testdriver.js for web app specific support.
>>
>> Flag namechrome://flags/#enable-desktop-pwas-launch-handler
>> kWebAppEnableLaunchHandler
>> 

Re: [blink-dev] Intent stage "Evaluate readiness to ship": web-share permission policy

[Matt Giuca]

Hi folks,

I've followed up on this internally at Google (talking to Chrome and
YouTube people) and also had a private thread with Marcos.

Marcos has proposed just changing the spec (and by extension, Gecko) to
make the permission policy be "*" by default, essentially codifying Chrome
and Safari's current behaviour of allowing embeds to use Web Share without
permission, but giving embedders the option to explicitly block it:
https://github.com/w3c/web-share/pull/234

My preference is actually to try and enforce the current spec (default of
"self") which would mean YT and other embeds are blocked from using Web
Share by default, unless granted permission by the embedder.

As I see it, the only major issue with YouTube being a huge user of Web
Share in iframes, is that the share button is apparently broken (as in, if
clicked, it throws a JS exception) if the permission is blocked. That's
simply a bug which we can get YouTube to fix (I am following up internally
with YouTube). If that bug is fixed, then I don't see a problem with the
share button falling back to use the internal in-page share UI (rather than
using the Web Share API) on the majority of embedded YT videos, with the
option for embedders to grant the permission if they want that UI to work.

Either way, we should come to a consensus on this and align the spec and
three implementations in relatively short order (O(days-weeks)).

Apologies that this issue has been left dangling for years.

Matt

On Fri, 27 May 2022 at 02:35, Joshua Bell  wrote:

> Thanks for the pings, Marcos. I'll try and have an update for you in the
> next week.
>
> On Thu, May 26, 2022 at 8:07 AM Marcos Caceres  wrote:
>
>> Just checking in again  I'm wondering if by chance folks here might be
>> to ping the YouTube folks one last time? It's been a while, so maybe they
>> will respond this time?
>>
>> Also, if we can try to get some cross-browser resolution around
>> permission policy for Web Share, it would be really great.
>>
>> On Friday, May 20, 2022 at 6:36:22 PM UTC+10 Marcos Caceres wrote:
>>
>>> Hi All,
>>>
>>> Coming back to this as it's now starting to cause Web compatibly issues
>>> across both Firefox and SafariTP (both of which implement `'self'`).
>>>
>>> I'm still worried that the ability to share files and other content (and
>>> even URLs, as we've seen in the past) is quite a powerful feature with
>>> security implications.
>>>
>>> However, we (other implementers) are facing a losing battle with Web
>>> compatibly here :(
>>>
>>> If it's too far gone, could we compromise with a "*" policy. But I'd
>>> like to get again get a sense if we can go with 'self'.
>>>
>>>
>>> On Monday, November 2, 2020 at 4:22:58 PM UTC+11 Matt Giuca wrote:
>>>
>>>> Pinging on this. It's been awhile and I don't think we've seen any
>>>> update on it. (Nobody from YouTube responded on the internal bug.)
>>>>
>>>> Eric, did measurements land and if so, what milestone will we start
>>>> seeing results in?
>>>>
>>>> On Fri, 4 Sep 2020 at 05:06, Chris Harrelson 
>>>> wrote:
>>>>
>>>>> Hi Eric,
>>>>>
>>>>> Did the analysis relating to Youtube complete? Do you think this will
>>>>> be safe to turn on, because the Youtube case was sufficiently special?
>>>>>
>>>>> Chris
>>>>>
>>>>> On Sun, Aug 23, 2020 at 10:03 PM Eric Willigers <
>>>>> ericwi...@chromium.org> wrote:
>>>>>
>>>>>>
>>>>>> On Friday, August 21, 2020 at 5:15:18 AM UTC+10, Mike West wrote:
>>>>>>>
>>>>>>> Have you followed up with YouTube internally? As Eric notes, it
>>>>>>> seems bad that this broke sharing in Canary.
>>>>>>>
>>>>>>
>>>>>> I have raised a YouTube issue internally, showing how to detect if
>>>>>> Feature Policy forbids sharing.
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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/e554e75c-f1cc-4a68-bac9-a7e8477c916bo

[blink-dev] Re: Intent to Prototype: Declarative Link Capturing for PWAs

[Matt Giuca]

Hi Som,

This API has evolved into a new design called "launch_handler" which is
more general than link capturing (allowing us to specify launch logic for
all kinds of app launches including share targets, file handlers, etc).

Intent:
https://groups.google.com/a/chromium.org/g/blink-dev/c/wNOClobsLrs/m/zo9KjKsoBwAJ?utm_medium=email_source=footer
Explainer: https://github.com/WICG/sw-launch/blob/main/launch_handler.md

The Declarative Link Capturing trial is scheduled to end after Chrome 97,
at which time the new API will be available and sites will need to adopt
the new syntax to continue having this functionality. (It will be possible
to have a site that supports the old and new syntax, with both the old and
new origin trials, to support both Chrome 97 and 98 at the same time.)

On Thu, 18 Nov 2021 at 18:57, Som Shahapurkar <
som.shahapur...@ironmountain.com> wrote:

> Hey Matt, has this moved beyond trial?
>
> On Wednesday, December 16, 2020 at 7:56:39 PM UTC-8 Matt Giuca wrote:
>
>> I just filed a TAG Review:
>> https://github.com/w3ctag/design-reviews/issues/589
>>
>> On Tue, 15 Dec 2020 at 18:03, yo...@yoav.ws  wrote:
>>
>>>
>>>
>>> On Monday, December 14, 2020 at 7:09:44 AM UTC+1 Matt Giuca wrote:
>>>
>>>> Contact emailsmgi...@chromium.org, alanc...@chromium.org,
>>>> c...@chromium.org
>>>>
>>>> Explainer
>>>>
>>>> https://github.com/WICG/sw-launch/blob/master/declarative_link_capturing.md
>>>>
>>>> SpecificationNone
>>>>
>>>> Summary
>>>>
>>>> New Web App Manifest members to control what happens when the user
>>>> navigates to a page within scope of an installed web app. This feature
>>>> introduces the "capture_links" member, an enumeration allowing the
>>>> customization of link capturing behaviour, allowing sites to: -
>>>> Automatically open a new PWA window when the user clicks a link to their
>>>> app. - Have a "single window mode" like mobile apps.
>>>>
>>>>
>>>> Blink componentUI>Browser>WebAppInstalls
>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:UI%3EBrowser%3EWebAppInstalls>
>>>>
>>>> Motivation
>>>>
>>>> After a user installs a PWA, currently the only way to open that PWA in
>>>> its standalone window is to launch it directly from the system launcher, or
>>>> use hard-to-discover Chrome menus to "pop out" web pages into the installed
>>>> app. Site developers commonly request the ability for when the user clicks
>>>> a link into their (already installed) app's scope, it automatically opens
>>>> the app window. This mirrors the behaviour of apps on mobile which do this
>>>> automatically. Site developers also frequently request the ability to, by
>>>> default, focus an existing instance of the app rather than opening a new
>>>> one. For example, a music player app doesn't make sense to open a second
>>>> instance.
>>>>
>>>> TAG reviewNone
>>>>
>>>
>>> Are you planning to file one?
>>>
>>>
>>>>
>>>>
>>>> TAG review statusPending
>>>>
>>>> Risks
>>>>
>>>>
>>>> Interoperability and Compatibility
>>>>
>>>> Very small, since any browser not implementing this will just fall back
>>>> to the standard behaviour, which is to navigate to links in a browser tab.
>>>> The design presents a forwards compatibility risk, which is that any new
>>>> modes added after the initial release would not be supported on earlier
>>>> browsers, forcing developers to break older browsers if they want to use
>>>> newer modes (similar to what happened with "display"). We can work around
>>>> this by accepting a fallback list.
>>>>
>>>>
>>>> Gecko: No signal
>>>>
>>>> WebKit: No signal
>>>>
>>>> Web developers: No signals
>>>>
>>>>
>>>> Is this feature fully tested by web-platform-tests
>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>
>>>> ?No
>>>>
>>>> Link to entry on the Chrome Platform Status
>>>> https://www.chromestatus.com/feature/5734953453092864
>>>>
>>>> This intent message was generated by Chrome Platform Status
>>&