Re: [blink-dev] Intent to Ship: Automatic Fullscreen Content Setting

[Mike Wasserman]

Permissions API query support is now reflected in the explainer [1] and the
prototype [2] will be enabled by default in M128 [3].
Thanks for all the reviews and input, please do share any additional
feedback.

[1]
https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture#permissions-api-integration
[2] https://chromium-review.googlesource.com/c/chromium/src/+/5583182
[3] https://chromium-review.googlesource.com/c/chromium/src/+/5665723


On Fri, May 17, 2024 at 2:43 AM Philip Jägenstedt 
wrote:

> Hi Mike,
>
> I think the use cases here are clear and skipping the user activation
> requirement is the only way to meet them. I believe that the biggest risk
> here is content written assuming this setting not working without it, and
> it being hard to understand why. In other words, debuggability and feature
> detection. Thank you for committing to the Permissions API query
> integration, that and good error messages addresses this risk.
>
> Thanks for also working on the spec for this. If this was a change to
> default behavior I'd want to await more input, but it's not, and the fact
> that this feature is only available to specific apps and origins massively
> reduces the risk that content on the web broadly comes to depend on this
> and breaks in other browsers.
>
> LGTM3
>
> On Thu, May 16, 2024 at 5:23 PM Vladimir Levin 
> wrote:
>
>> LGTM2
>>
>> On Thu, May 16, 2024 at 11:16 AM Mike Taylor 
>> wrote:
>>
>>> LGTM1, with the commitment to follow up on Permissions API integration
>>> (thanks!).
>>> On 5/15/24 6:34 PM, Reilly Grant wrote:
>>>
>>> LGTM as an IWA OWNER (3x LGTM from Blink API OWNERS are still required
>>> according to the IWA-specific API launch process
>>> ).
>>>
>>>
>>> Thank you for working with the IWA and Security reviewers to figure out
>>> the right restrictions to prevent this from exacerbating fullscreen-based
>>> phishing attacks. We have the option to loosen these restrictions if a
>>> better UX solution to the notice and consent is developed.
>>> Reilly Grant | Software Engineer | reil...@chromium.org | Google Chrome
>>> 
>>>
>>>
>>> On Wed, May 15, 2024 at 3:00 PM Mike Wasserman  wrote:
>>>
 Our team can commit to adding Permissions API query integration, with
 the requisite approvals.
 That would provide feature detection, and also clarify
 requestFullscreen method steps in the spec.

 I'm requesting approval to ship the feature in its current state, given
 our commitment to follow up.

 Thanks,
 Mike


 On Wed, May 15, 2024 at 10:01 AM Mike Wasserman 
 wrote:

> No, this content setting does not have Permissions API integration at
> this time.
> That seems like a great future improvement, especially if user control
> of the setting is extended to more contexts.
>
> On Wed, May 15, 2024 at 9:37 AM Alex Russell 
> wrote:
>
>> Will the status of the permission be reflected in the Permissions
>> API? I see Permissions Policy integration, but not the Permissions API
>> reflection that I'd expect.
>>
>> Best,
>>
>> Alex
>>
>> On Tuesday, May 14, 2024 at 3:54:24 PM UTC-7 Mike Wasserman wrote:
>>
>>> Thanks! I pinged the PR, and hope for some feedback there soon.
>>>
>>> Feature detection via Permissions API querying seems like a great
>>> follow up here, ideally alongside broadened feature availability (i.e.
>>> extending user control beyond Isolated Web Apps).
>>>
>>>
>>> On Tue, May 14, 2024 at 1:43 PM Mike Taylor 
>>> wrote:
>>>
 It would be nice for the PR to be reviewed and approved, even
 without other stakeholder support.

 Additionally - the explainer mentions a few options for feature
 detection. Any progress on that front? Or is it just hypothetical?
 On 5/9/24 3:04 PM, Mike Wasserman wrote:

 Sure. I'll note that whatwg/fullscreen's PR merging includes a
 question or criteria "At least two implementers are interested (and 
 none
 opposed)".
 I have filed standards position requests with Mozilla and WebKit,
 and I will ping fullscreen spec maintainers for input.

 On Thu, May 9, 2024 at 11:39 AM Vladimir Levin 
 wrote:

> Ah thanks, I missed it in the explainer. The spec changes make
> sense to me. The changes don't look like they would be controversial, 
> but
> it's probably worthwhile to ensure that this PR is under review and/or
> landing as a part of shipping this.
>
> Thanks!
> Vlad
>
> On Thu, May 9, 2024 at 12:20 PM Mike Wasserman 
> wrote:
>
>> Yes, there's a draft PR
>>  with the
>> E

Re: [blink-dev] Intent to Ship: Automatic Fullscreen Content Setting

[Philip Jägenstedt]

Hi Mike,

I think the use cases here are clear and skipping the user activation
requirement is the only way to meet them. I believe that the biggest risk
here is content written assuming this setting not working without it, and
it being hard to understand why. In other words, debuggability and feature
detection. Thank you for committing to the Permissions API query
integration, that and good error messages addresses this risk.

Thanks for also working on the spec for this. If this was a change to
default behavior I'd want to await more input, but it's not, and the fact
that this feature is only available to specific apps and origins massively
reduces the risk that content on the web broadly comes to depend on this
and breaks in other browsers.

LGTM3

On Thu, May 16, 2024 at 5:23 PM Vladimir Levin  wrote:

> LGTM2
>
> On Thu, May 16, 2024 at 11:16 AM Mike Taylor 
> wrote:
>
>> LGTM1, with the commitment to follow up on Permissions API integration
>> (thanks!).
>> On 5/15/24 6:34 PM, Reilly Grant wrote:
>>
>> LGTM as an IWA OWNER (3x LGTM from Blink API OWNERS are still required
>> according to the IWA-specific API launch process
>> ).
>>
>> Thank you for working with the IWA and Security reviewers to figure out
>> the right restrictions to prevent this from exacerbating fullscreen-based
>> phishing attacks. We have the option to loosen these restrictions if a
>> better UX solution to the notice and consent is developed.
>> Reilly Grant | Software Engineer | reil...@chromium.org | Google Chrome
>> 
>>
>>
>> On Wed, May 15, 2024 at 3:00 PM Mike Wasserman  wrote:
>>
>>> Our team can commit to adding Permissions API query integration, with
>>> the requisite approvals.
>>> That would provide feature detection, and also clarify requestFullscreen
>>> method steps in the spec.
>>>
>>> I'm requesting approval to ship the feature in its current state, given
>>> our commitment to follow up.
>>>
>>> Thanks,
>>> Mike
>>>
>>>
>>> On Wed, May 15, 2024 at 10:01 AM Mike Wasserman 
>>> wrote:
>>>
 No, this content setting does not have Permissions API integration at
 this time.
 That seems like a great future improvement, especially if user control
 of the setting is extended to more contexts.

 On Wed, May 15, 2024 at 9:37 AM Alex Russell 
 wrote:

> Will the status of the permission be reflected in the Permissions API?
> I see Permissions Policy integration, but not the Permissions API
> reflection that I'd expect.
>
> Best,
>
> Alex
>
> On Tuesday, May 14, 2024 at 3:54:24 PM UTC-7 Mike Wasserman wrote:
>
>> Thanks! I pinged the PR, and hope for some feedback there soon.
>>
>> Feature detection via Permissions API querying seems like a great
>> follow up here, ideally alongside broadened feature availability (i.e.
>> extending user control beyond Isolated Web Apps).
>>
>>
>> On Tue, May 14, 2024 at 1:43 PM Mike Taylor 
>> wrote:
>>
>>> It would be nice for the PR to be reviewed and approved, even
>>> without other stakeholder support.
>>>
>>> Additionally - the explainer mentions a few options for feature
>>> detection. Any progress on that front? Or is it just hypothetical?
>>> On 5/9/24 3:04 PM, Mike Wasserman wrote:
>>>
>>> Sure. I'll note that whatwg/fullscreen's PR merging includes a
>>> question or criteria "At least two implementers are interested (and none
>>> opposed)".
>>> I have filed standards position requests with Mozilla and WebKit,
>>> and I will ping fullscreen spec maintainers for input.
>>>
>>> On Thu, May 9, 2024 at 11:39 AM Vladimir Levin 
>>> wrote:
>>>
 Ah thanks, I missed it in the explainer. The spec changes make
 sense to me. The changes don't look like they would be controversial, 
 but
 it's probably worthwhile to ensure that this PR is under review and/or
 landing as a part of shipping this.

 Thanks!
 Vlad

 On Thu, May 9, 2024 at 12:20 PM Mike Wasserman 
 wrote:

> Yes, there's a draft PR
>  with the
> Explainer's anticipated spec changes
> ,
> which are designed
> 
>  alike The rules for choosing a navigable
> 
> when a new top-level traversable
> 
> is being requested, as invoked by Window.open()

Re: [blink-dev] Intent to Ship: Automatic Fullscreen Content Setting

[Vladimir Levin]

LGTM2

On Thu, May 16, 2024 at 11:16 AM Mike Taylor  wrote:

> LGTM1, with the commitment to follow up on Permissions API integration
> (thanks!).
> On 5/15/24 6:34 PM, Reilly Grant wrote:
>
> LGTM as an IWA OWNER (3x LGTM from Blink API OWNERS are still required
> according to the IWA-specific API launch process
> ).
>
> Thank you for working with the IWA and Security reviewers to figure out
> the right restrictions to prevent this from exacerbating fullscreen-based
> phishing attacks. We have the option to loosen these restrictions if a
> better UX solution to the notice and consent is developed.
> Reilly Grant | Software Engineer | reil...@chromium.org | Google Chrome
> 
>
>
> On Wed, May 15, 2024 at 3:00 PM Mike Wasserman  wrote:
>
>> Our team can commit to adding Permissions API query integration, with the
>> requisite approvals.
>> That would provide feature detection, and also clarify requestFullscreen
>> method steps in the spec.
>>
>> I'm requesting approval to ship the feature in its current state, given
>> our commitment to follow up.
>>
>> Thanks,
>> Mike
>>
>>
>> On Wed, May 15, 2024 at 10:01 AM Mike Wasserman  wrote:
>>
>>> No, this content setting does not have Permissions API integration at
>>> this time.
>>> That seems like a great future improvement, especially if user control
>>> of the setting is extended to more contexts.
>>>
>>> On Wed, May 15, 2024 at 9:37 AM Alex Russell 
>>> wrote:
>>>
 Will the status of the permission be reflected in the Permissions API?
 I see Permissions Policy integration, but not the Permissions API
 reflection that I'd expect.

 Best,

 Alex

 On Tuesday, May 14, 2024 at 3:54:24 PM UTC-7 Mike Wasserman wrote:

> Thanks! I pinged the PR, and hope for some feedback there soon.
>
> Feature detection via Permissions API querying seems like a great
> follow up here, ideally alongside broadened feature availability (i.e.
> extending user control beyond Isolated Web Apps).
>
>
> On Tue, May 14, 2024 at 1:43 PM Mike Taylor 
> wrote:
>
>> It would be nice for the PR to be reviewed and approved, even without
>> other stakeholder support.
>>
>> Additionally - the explainer mentions a few options for feature
>> detection. Any progress on that front? Or is it just hypothetical?
>> On 5/9/24 3:04 PM, Mike Wasserman wrote:
>>
>> Sure. I'll note that whatwg/fullscreen's PR merging includes a
>> question or criteria "At least two implementers are interested (and none
>> opposed)".
>> I have filed standards position requests with Mozilla and WebKit, and
>> I will ping fullscreen spec maintainers for input.
>>
>> On Thu, May 9, 2024 at 11:39 AM Vladimir Levin 
>> wrote:
>>
>>> Ah thanks, I missed it in the explainer. The spec changes make sense
>>> to me. The changes don't look like they would be controversial, but it's
>>> probably worthwhile to ensure that this PR is under review and/or 
>>> landing
>>> as a part of shipping this.
>>>
>>> Thanks!
>>> Vlad
>>>
>>> On Thu, May 9, 2024 at 12:20 PM Mike Wasserman 
>>> wrote:
>>>
 Yes, there's a draft PR
  with the
 Explainer's anticipated spec changes
 ,
 which are designed
 
  alike The rules for choosing a navigable
 
 when a new top-level traversable
 
 is being requested, as invoked by Window.open()
 :


- If currentNavigable's active window

 
does not have transient activation

 
and the user agent has been configured to not show popups (i.e., 
 the user
agent has a "popup blocker" enabled)
   - The user agent may inform the user that a popup has been
   blocked.


 On Thursday, May 9, 2024 at 7:30:09 AM UTC-7 Vladimir Levin wrote:

> On Wed, May 8, 2024 at 7:46 PM Mike Wasserman 
> wrote:
>
>> Contact emails
>>
>> m...@chromium.org, fugu-...@chromium.org
>>
>>>

Re: [blink-dev] Intent to Ship: Automatic Fullscreen Content Setting

[Mike Taylor]

LGTM1, with the commitment to follow up on Permissions API integration 
(thanks!).


On 5/15/24 6:34 PM, Reilly Grant wrote:
LGTM as an IWA OWNER (3x LGTM from Blink API OWNERS are still required 
according to the IWA-specific API launch process 
).


Thank you for working with the IWA and Security reviewers to figure 
out the right restrictions to prevent this from 
exacerbating fullscreen-based phishing attacks. We have the option to 
loosen these restrictions if a better UX solution to the notice and 
consent is developed.
Reilly Grant | Software Engineer |reil...@chromium.org |Google Chrome 




On Wed, May 15, 2024 at 3:00 PM Mike Wasserman  wrote:

Our team can commit to adding Permissions API query integration,
with the requisite approvals.
That would provide feature detection, and also clarify
requestFullscreen method steps in the spec.

I'm requesting approval to ship the feature in its current state,
given our commitment to follow up.

Thanks,
Mike


On Wed, May 15, 2024 at 10:01 AM Mike Wasserman 
wrote:

No, this content setting does not have Permissions API
integration at this time.
That seems like a great future improvement, especially if user
control of the setting is extended to more contexts.

On Wed, May 15, 2024 at 9:37 AM Alex Russell
 wrote:

Will the status of the permission be reflected in the
Permissions API? I see Permissions Policy integration, but
not the Permissions API reflection that I'd expect.

Best,

Alex

On Tuesday, May 14, 2024 at 3:54:24 PM UTC-7 Mike
Wasserman wrote:

Thanks! I pinged the PR, and hope for some feedback
there soon.

Feature detection via Permissions API querying seems
like a great follow up here, ideally alongside
broadened feature availability (i.e. extending user
control beyond Isolated Web Apps).


On Tue, May 14, 2024 at 1:43 PM Mike Taylor
 wrote:

It would be nice for the PR to be reviewed and
approved, even without other stakeholder support.

Additionally - the explainer mentions a few
options for feature detection. Any progress on
that front? Or is it just hypothetical?

On 5/9/24 3:04 PM, Mike Wasserman wrote:

Sure. I'll note that whatwg/fullscreen's PR
merging includes a question or criteria "At least
two implementers are interested (and none opposed)".
I have filed standards position requests with
Mozilla and WebKit, and I will ping fullscreen
spec maintainers for input.

On Thu, May 9, 2024 at 11:39 AM Vladimir Levin
 wrote:

Ah thanks, I missed it in the explainer. The
spec changes make sense to me. The changes
don't look like they would be controversial,
but it's probably worthwhile to ensure that
this PR is under review and/or landing as a
part of shipping this.

Thanks!
Vlad

On Thu, May 9, 2024 at 12:20 PM Mike
Wasserman  wrote:

Yes, there's a draft PR

with the Explainer's anticipated spec
changes

,
which are designed


 alike
The rules for choosing a navigable


when a new top-level traversable


is being requested, as invoked by
Window.open()

:


  * If currentNavigable's active window

Re: [blink-dev] Intent to Ship: Automatic Fullscreen Content Setting

[Reilly Grant]

LGTM as an IWA OWNER (3x LGTM from Blink API OWNERS are still required
according to the IWA-specific API launch process
).

Thank you for working with the IWA and Security reviewers to figure out the
right restrictions to prevent this from exacerbating fullscreen-based
phishing attacks. We have the option to loosen these restrictions if a
better UX solution to the notice and consent is developed.
Reilly Grant | Software Engineer | reil...@chromium.org | Google Chrome



On Wed, May 15, 2024 at 3:00 PM Mike Wasserman  wrote:

> Our team can commit to adding Permissions API query integration, with the
> requisite approvals.
> That would provide feature detection, and also clarify requestFullscreen
> method steps in the spec.
>
> I'm requesting approval to ship the feature in its current state, given
> our commitment to follow up.
>
> Thanks,
> Mike
>
>
> On Wed, May 15, 2024 at 10:01 AM Mike Wasserman  wrote:
>
>> No, this content setting does not have Permissions API integration at
>> this time.
>> That seems like a great future improvement, especially if user control of
>> the setting is extended to more contexts.
>>
>> On Wed, May 15, 2024 at 9:37 AM Alex Russell 
>> wrote:
>>
>>> Will the status of the permission be reflected in the Permissions API? I
>>> see Permissions Policy integration, but not the Permissions API reflection
>>> that I'd expect.
>>>
>>> Best,
>>>
>>> Alex
>>>
>>> On Tuesday, May 14, 2024 at 3:54:24 PM UTC-7 Mike Wasserman wrote:
>>>
 Thanks! I pinged the PR, and hope for some feedback there soon.

 Feature detection via Permissions API querying seems like a great
 follow up here, ideally alongside broadened feature availability (i.e.
 extending user control beyond Isolated Web Apps).


 On Tue, May 14, 2024 at 1:43 PM Mike Taylor 
 wrote:

> It would be nice for the PR to be reviewed and approved, even without
> other stakeholder support.
>
> Additionally - the explainer mentions a few options for feature
> detection. Any progress on that front? Or is it just hypothetical?
> On 5/9/24 3:04 PM, Mike Wasserman wrote:
>
> Sure. I'll note that whatwg/fullscreen's PR merging includes a
> question or criteria "At least two implementers are interested (and none
> opposed)".
> I have filed standards position requests with Mozilla and WebKit, and
> I will ping fullscreen spec maintainers for input.
>
> On Thu, May 9, 2024 at 11:39 AM Vladimir Levin 
> wrote:
>
>> Ah thanks, I missed it in the explainer. The spec changes make sense
>> to me. The changes don't look like they would be controversial, but it's
>> probably worthwhile to ensure that this PR is under review and/or landing
>> as a part of shipping this.
>>
>> Thanks!
>> Vlad
>>
>> On Thu, May 9, 2024 at 12:20 PM Mike Wasserman 
>> wrote:
>>
>>> Yes, there's a draft PR
>>>  with the
>>> Explainer's anticipated spec changes
>>> ,
>>> which are designed
>>> 
>>>  alike The rules for choosing a navigable
>>> 
>>> when a new top-level traversable
>>> 
>>> is being requested, as invoked by Window.open()
>>> :
>>>
>>>
>>>- If currentNavigable's active window
>>>
>>> 
>>>does not have transient activation
>>>
>>> 
>>>and the user agent has been configured to not show popups (i.e., the 
>>> user
>>>agent has a "popup blocker" enabled)
>>>   - The user agent may inform the user that a popup has been
>>>   blocked.
>>>
>>>
>>> On Thursday, May 9, 2024 at 7:30:09 AM UTC-7 Vladimir Levin wrote:
>>>
 On Wed, May 8, 2024 at 7:46 PM Mike Wasserman 
 wrote:

> Contact emails
>
> m...@chromium.org, fugu-...@chromium.org
>
> Explainer
>
>
> https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture
>
> Specification
>
> https://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen
>
> Design docs
>
>
> https://github.com/expla

Re: [blink-dev] Intent to Ship: Automatic Fullscreen Content Setting

[Mike Wasserman]

Our team can commit to adding Permissions API query integration, with the
requisite approvals.
That would provide feature detection, and also clarify requestFullscreen
method steps in the spec.

I'm requesting approval to ship the feature in its current state, given our
commitment to follow up.

Thanks,
Mike


On Wed, May 15, 2024 at 10:01 AM Mike Wasserman  wrote:

> No, this content setting does not have Permissions API integration at this
> time.
> That seems like a great future improvement, especially if user control of
> the setting is extended to more contexts.
>
> On Wed, May 15, 2024 at 9:37 AM Alex Russell 
> wrote:
>
>> Will the status of the permission be reflected in the Permissions API? I
>> see Permissions Policy integration, but not the Permissions API reflection
>> that I'd expect.
>>
>> Best,
>>
>> Alex
>>
>> On Tuesday, May 14, 2024 at 3:54:24 PM UTC-7 Mike Wasserman wrote:
>>
>>> Thanks! I pinged the PR, and hope for some feedback there soon.
>>>
>>> Feature detection via Permissions API querying seems like a great follow
>>> up here, ideally alongside broadened feature availability (i.e. extending
>>> user control beyond Isolated Web Apps).
>>>
>>>
>>> On Tue, May 14, 2024 at 1:43 PM Mike Taylor 
>>> wrote:
>>>
 It would be nice for the PR to be reviewed and approved, even without
 other stakeholder support.

 Additionally - the explainer mentions a few options for feature
 detection. Any progress on that front? Or is it just hypothetical?
 On 5/9/24 3:04 PM, Mike Wasserman wrote:

 Sure. I'll note that whatwg/fullscreen's PR merging includes a question
 or criteria "At least two implementers are interested (and none opposed)".
 I have filed standards position requests with Mozilla and WebKit, and I
 will ping fullscreen spec maintainers for input.

 On Thu, May 9, 2024 at 11:39 AM Vladimir Levin 
 wrote:

> Ah thanks, I missed it in the explainer. The spec changes make sense
> to me. The changes don't look like they would be controversial, but it's
> probably worthwhile to ensure that this PR is under review and/or landing
> as a part of shipping this.
>
> Thanks!
> Vlad
>
> On Thu, May 9, 2024 at 12:20 PM Mike Wasserman 
> wrote:
>
>> Yes, there's a draft PR
>>  with the Explainer's 
>> anticipated
>> spec changes
>> ,
>> which are designed
>> 
>>  alike The rules for choosing a navigable
>> 
>> when a new top-level traversable
>> 
>> is being requested, as invoked by Window.open()
>> :
>>
>>
>>- If currentNavigable's active window
>>
>> 
>>does not have transient activation
>>
>> 
>>and the user agent has been configured to not show popups (i.e., the 
>> user
>>agent has a "popup blocker" enabled)
>>   - The user agent may inform the user that a popup has been
>>   blocked.
>>
>>
>> On Thursday, May 9, 2024 at 7:30:09 AM UTC-7 Vladimir Levin wrote:
>>
>>> On Wed, May 8, 2024 at 7:46 PM Mike Wasserman 
>>> wrote:
>>>
 Contact emails

 m...@chromium.org, fugu-...@chromium.org

 Explainer


 https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture

 Specification

 https://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen

 Design docs


 https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture

 Summary

 A new "Automatic Fullscreen" content setting permits
 Element.requestFullscreen() without a user gesture, and permits browser
 dialogs to appear without exiting fullscreen.

 The setting is blocked by default and sites cannot prompt for
 permission. New UI controls are limited to Chrome's settings pages [1] 
 and
 the site info bubble. Users can allow Isolated Web Apps [2], and 
 enterprise
 admins can allow additional origins with the
 AutomaticFullscreenAllowedForUrls policy.

 Combined with Window Management permission [3] and unblocked popups
 [4

Re: [blink-dev] Intent to Ship: Automatic Fullscreen Content Setting

[Mike Wasserman]

No, this content setting does not have Permissions API integration at this
time.
That seems like a great future improvement, especially if user control of
the setting is extended to more contexts.

On Wed, May 15, 2024 at 9:37 AM Alex Russell 
wrote:

> Will the status of the permission be reflected in the Permissions API? I
> see Permissions Policy integration, but not the Permissions API reflection
> that I'd expect.
>
> Best,
>
> Alex
>
> On Tuesday, May 14, 2024 at 3:54:24 PM UTC-7 Mike Wasserman wrote:
>
>> Thanks! I pinged the PR, and hope for some feedback there soon.
>>
>> Feature detection via Permissions API querying seems like a great follow
>> up here, ideally alongside broadened feature availability (i.e. extending
>> user control beyond Isolated Web Apps).
>>
>>
>> On Tue, May 14, 2024 at 1:43 PM Mike Taylor 
>> wrote:
>>
>>> It would be nice for the PR to be reviewed and approved, even without
>>> other stakeholder support.
>>>
>>> Additionally - the explainer mentions a few options for feature
>>> detection. Any progress on that front? Or is it just hypothetical?
>>> On 5/9/24 3:04 PM, Mike Wasserman wrote:
>>>
>>> Sure. I'll note that whatwg/fullscreen's PR merging includes a question
>>> or criteria "At least two implementers are interested (and none opposed)".
>>> I have filed standards position requests with Mozilla and WebKit, and I
>>> will ping fullscreen spec maintainers for input.
>>>
>>> On Thu, May 9, 2024 at 11:39 AM Vladimir Levin 
>>> wrote:
>>>
 Ah thanks, I missed it in the explainer. The spec changes make sense to
 me. The changes don't look like they would be controversial, but it's
 probably worthwhile to ensure that this PR is under review and/or landing
 as a part of shipping this.

 Thanks!
 Vlad

 On Thu, May 9, 2024 at 12:20 PM Mike Wasserman 
 wrote:

> Yes, there's a draft PR
>  with the Explainer's 
> anticipated
> spec changes
> ,
> which are designed
> 
>  alike The rules for choosing a navigable
> 
> when a new top-level traversable
> 
> is being requested, as invoked by Window.open()
> :
>
>
>- If currentNavigable's active window
>
> 
>does not have transient activation
>
> 
>and the user agent has been configured to not show popups (i.e., the 
> user
>agent has a "popup blocker" enabled)
>   - The user agent may inform the user that a popup has been
>   blocked.
>
>
> On Thursday, May 9, 2024 at 7:30:09 AM UTC-7 Vladimir Levin wrote:
>
>> On Wed, May 8, 2024 at 7:46 PM Mike Wasserman 
>> wrote:
>>
>>> Contact emails
>>>
>>> m...@chromium.org, fugu-...@chromium.org
>>>
>>> Explainer
>>>
>>>
>>> https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture
>>>
>>> Specification
>>>
>>> https://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen
>>>
>>> Design docs
>>>
>>>
>>> https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture
>>>
>>> Summary
>>>
>>> A new "Automatic Fullscreen" content setting permits
>>> Element.requestFullscreen() without a user gesture, and permits browser
>>> dialogs to appear without exiting fullscreen.
>>>
>>> The setting is blocked by default and sites cannot prompt for
>>> permission. New UI controls are limited to Chrome's settings pages [1] 
>>> and
>>> the site info bubble. Users can allow Isolated Web Apps [2], and 
>>> enterprise
>>> admins can allow additional origins with the
>>> AutomaticFullscreenAllowedForUrls policy.
>>>
>>> Combined with Window Management permission [3] and unblocked popups
>>> [4], this unlocks valuable fullscreen capabilities:
>>>
>>> - Open a fullscreen popup on another display, from one gesture
>>>
>>> - Show fullscreen content on multiple displays from one gesture
>>>
>>> - Show fullscreen content on a new display, when it's connected
>>>
>>> - Swap fullscreen windows between displays with one gesture
>>>
>>> - Show fullscreen content after user gesture expiry or consumption
>>>
>>> [1] chrome://settings/content/au

Re: [blink-dev] Intent to Ship: Automatic Fullscreen Content Setting

[Alex Russell]

Will the status of the permission be reflected in the Permissions API? I 
see Permissions Policy integration, but not the Permissions API reflection 
that I'd expect.

Best,

Alex

On Tuesday, May 14, 2024 at 3:54:24 PM UTC-7 Mike Wasserman wrote:

> Thanks! I pinged the PR, and hope for some feedback there soon.
>
> Feature detection via Permissions API querying seems like a great follow 
> up here, ideally alongside broadened feature availability (i.e. extending 
> user control beyond Isolated Web Apps).
>
>
> On Tue, May 14, 2024 at 1:43 PM Mike Taylor  
> wrote:
>
>> It would be nice for the PR to be reviewed and approved, even without 
>> other stakeholder support.
>>
>> Additionally - the explainer mentions a few options for feature 
>> detection. Any progress on that front? Or is it just hypothetical?
>> On 5/9/24 3:04 PM, Mike Wasserman wrote:
>>
>> Sure. I'll note that whatwg/fullscreen's PR merging includes a question 
>> or criteria "At least two implementers are interested (and none opposed)". 
>> I have filed standards position requests with Mozilla and WebKit, and I 
>> will ping fullscreen spec maintainers for input.
>>
>> On Thu, May 9, 2024 at 11:39 AM Vladimir Levin  
>> wrote:
>>
>>> Ah thanks, I missed it in the explainer. The spec changes make sense to 
>>> me. The changes don't look like they would be controversial, but it's 
>>> probably worthwhile to ensure that this PR is under review and/or landing 
>>> as a part of shipping this. 
>>>
>>> Thanks!
>>> Vlad
>>>
>>> On Thu, May 9, 2024 at 12:20 PM Mike Wasserman  wrote:
>>>
 Yes, there's a draft PR  
 with the Explainer's anticipated spec changes 
 ,
  
 which are designed 
 
  alike The rules for choosing a navigable 
 
  
 when a new top-level traversable 
 
  
 is being requested, as invoked by Window.open() 
 :
  


- If currentNavigable's active window 

 
  
does not have transient activation 

 
  
and the user agent has been configured to not show popups (i.e., the 
 user 
agent has a "popup blocker" enabled) 
   - The user agent may inform the user that a popup has been 
   blocked. 


 On Thursday, May 9, 2024 at 7:30:09 AM UTC-7 Vladimir Levin wrote:

> On Wed, May 8, 2024 at 7:46 PM Mike Wasserman  
> wrote:
>
>> Contact emails 
>>
>> m...@chromium.org, fugu-...@chromium.org
>>
>> Explainer 
>>
>>
>> https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture
>>
>> Specification 
>>
>> https://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen
>>
>> Design docs 
>>
>>
>> https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture
>>
>> Summary 
>>
>> A new "Automatic Fullscreen" content setting permits 
>> Element.requestFullscreen() without a user gesture, and permits browser 
>> dialogs to appear without exiting fullscreen.
>>
>> The setting is blocked by default and sites cannot prompt for 
>> permission. New UI controls are limited to Chrome's settings pages [1] 
>> and 
>> the site info bubble. Users can allow Isolated Web Apps [2], and 
>> enterprise 
>> admins can allow additional origins with the 
>> AutomaticFullscreenAllowedForUrls policy.
>>
>> Combined with Window Management permission [3] and unblocked popups 
>> [4], this unlocks valuable fullscreen capabilities:
>>
>> - Open a fullscreen popup on another display, from one gesture
>>
>> - Show fullscreen content on multiple displays from one gesture
>>
>> - Show fullscreen content on a new display, when it's connected
>>
>> - Swap fullscreen windows between displays with one gesture
>>
>> - Show fullscreen content after user gesture expiry or consumption
>>
>> [1] chrome://settings/content/automaticFullScreen and site details 
>> pages
>>
>> [2] User control is initially scoped to security-sensitive apps; see 
>> https://chromestatus.com/feature/5146307550248960
>>
>> [3] For multi-screen window placement features; see 
>> https://chromestatus.com/feature/525296058394214

Re: [blink-dev] Intent to Ship: Automatic Fullscreen Content Setting

[Mike Wasserman]

Thanks! I pinged the PR, and hope for some feedback there soon.

Feature detection via Permissions API querying seems like a great follow up
here, ideally alongside broadened feature availability (i.e. extending user
control beyond Isolated Web Apps).


On Tue, May 14, 2024 at 1:43 PM Mike Taylor  wrote:

> It would be nice for the PR to be reviewed and approved, even without
> other stakeholder support.
>
> Additionally - the explainer mentions a few options for feature detection.
> Any progress on that front? Or is it just hypothetical?
> On 5/9/24 3:04 PM, Mike Wasserman wrote:
>
> Sure. I'll note that whatwg/fullscreen's PR merging includes a question or
> criteria "At least two implementers are interested (and none opposed)".
> I have filed standards position requests with Mozilla and WebKit, and I
> will ping fullscreen spec maintainers for input.
>
> On Thu, May 9, 2024 at 11:39 AM Vladimir Levin 
> wrote:
>
>> Ah thanks, I missed it in the explainer. The spec changes make sense to
>> me. The changes don't look like they would be controversial, but it's
>> probably worthwhile to ensure that this PR is under review and/or landing
>> as a part of shipping this.
>>
>> Thanks!
>> Vlad
>>
>> On Thu, May 9, 2024 at 12:20 PM Mike Wasserman  wrote:
>>
>>> Yes, there's a draft PR 
>>> with the Explainer's anticipated spec changes
>>> ,
>>> which are designed
>>> 
>>>  alike The rules for choosing a navigable
>>> 
>>> when a new top-level traversable
>>> 
>>> is being requested, as invoked by Window.open()
>>> :
>>>
>>>
>>>- If currentNavigable's active window
>>>
>>> 
>>>does not have transient activation
>>>
>>> 
>>>and the user agent has been configured to not show popups (i.e., the user
>>>agent has a "popup blocker" enabled)
>>>   - The user agent may inform the user that a popup has been
>>>   blocked.
>>>
>>>
>>> On Thursday, May 9, 2024 at 7:30:09 AM UTC-7 Vladimir Levin wrote:
>>>
 On Wed, May 8, 2024 at 7:46 PM Mike Wasserman  wrote:

> Contact emails
>
> m...@chromium.org, fugu-...@chromium.org
>
> Explainer
>
>
> https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture
>
> Specification
>
> https://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen
>
> Design docs
>
>
> https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture
>
> Summary
>
> A new "Automatic Fullscreen" content setting permits
> Element.requestFullscreen() without a user gesture, and permits browser
> dialogs to appear without exiting fullscreen.
>
> The setting is blocked by default and sites cannot prompt for
> permission. New UI controls are limited to Chrome's settings pages [1] and
> the site info bubble. Users can allow Isolated Web Apps [2], and 
> enterprise
> admins can allow additional origins with the
> AutomaticFullscreenAllowedForUrls policy.
>
> Combined with Window Management permission [3] and unblocked popups
> [4], this unlocks valuable fullscreen capabilities:
>
> - Open a fullscreen popup on another display, from one gesture
>
> - Show fullscreen content on multiple displays from one gesture
>
> - Show fullscreen content on a new display, when it's connected
>
> - Swap fullscreen windows between displays with one gesture
>
> - Show fullscreen content after user gesture expiry or consumption
>
> [1] chrome://settings/content/automaticFullScreen and site details
> pages
>
> [2] User control is initially scoped to security-sensitive apps; see
> https://chromestatus.com/feature/5146307550248960
>
> [3] For multi-screen window placement features; see
> https://chromestatus.com/feature/5252960583942144
>
> [4] To similarly permit window.open() without a user gesture; see
> chrome://settings/content/popups
>
> Blink component
>
> Blink>Fullscreen
> 
>
> Search tags
>
> Fullscreen ,
> requestFullscreen
> , transient
> activati

Re: [blink-dev] Intent to Ship: Automatic Fullscreen Content Setting

[Mike Taylor]

It would be nice for the PR to be reviewed and approved, even without 
other stakeholder support.


Additionally - the explainer mentions a few options for feature 
detection. Any progress on that front? Or is it just hypothetical?


On 5/9/24 3:04 PM, Mike Wasserman wrote:
Sure. I'll note that whatwg/fullscreen's PR merging includes a 
question or criteria "At least two implementers are interested (and 
none opposed)".
I have filed standards position requests with Mozilla and WebKit, and 
I will ping fullscreen spec maintainers for input.


On Thu, May 9, 2024 at 11:39 AM Vladimir Levin  
wrote:


Ah thanks, I missed it in the explainer. The spec changes make
sense to me. The changes don't look like they would be
controversial, but it's probably worthwhile to ensure that this PR
is under review and/or landing as a part of shipping this.

Thanks!
Vlad

On Thu, May 9, 2024 at 12:20 PM Mike Wasserman 
wrote:

Yes, there's a draft PR
 with the
Explainer's anticipated spec changes

,
which are designed


 alike
The rules for choosing a navigable


when a new top-level traversable


is being requested, as invoked by Window.open()

:


  * If currentNavigable's active window


does not have transient activation


and the user agent has been configured to not show popups
(i.e., the user agent has a "popup blocker" enabled)
  o The user agent may inform the user that a popup has
been blocked.


On Thursday, May 9, 2024 at 7:30:09 AM UTC-7 Vladimir Levin wrote:

On Wed, May 8, 2024 at 7:46 PM Mike Wasserman
 wrote:


Contact emails

m...@chromium.org, fugu-...@chromium.org


Explainer


https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture




Specification


https://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen




Design docs


https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture




Summary

A new "Automatic Fullscreen" content setting permits
Element.requestFullscreen() without a user gesture,
and permits browser dialogs to appear without exiting
fullscreen.


The setting is blocked by default and sites cannot
prompt for permission. New UI controls are limited to
Chrome's settings pages [1] and the site info bubble.
Users can allow Isolated Web Apps [2], and enterprise
admins can allow additional origins with the
AutomaticFullscreenAllowedForUrls policy.


Combined with Window Management permission [3] and
unblocked popups [4], this unlocks valuable fullscreen
capabilities:

- Open a fullscreen popup on another display, from one
gesture

- Show fullscreen content on multiple displays from
one gesture

- Show fullscreen content on a new display, when it's
connected

- Swap fullscreen windows between displays with one
gesture

- Show fullscreen content after user gesture expiry or
consumption


[1] chrome://settings/content/automaticFullScreen and
site details pages

[2] User control is initially scoped to
security-sensitive apps;
seehttps://chromestatus.com/feature/5146307550248960


[3] For multi-screen window placement features;
seehttps://chromestatus.com/featur

Re: [blink-dev] Intent to Ship: Automatic Fullscreen Content Setting

[Mike Wasserman]

Sure. I'll note that whatwg/fullscreen's PR merging includes a question or
criteria "At least two implementers are interested (and none opposed)".
I have filed standards position requests with Mozilla and WebKit, and I
will ping fullscreen spec maintainers for input.

On Thu, May 9, 2024 at 11:39 AM Vladimir Levin  wrote:

> Ah thanks, I missed it in the explainer. The spec changes make sense to
> me. The changes don't look like they would be controversial, but it's
> probably worthwhile to ensure that this PR is under review and/or landing
> as a part of shipping this.
>
> Thanks!
> Vlad
>
> On Thu, May 9, 2024 at 12:20 PM Mike Wasserman  wrote:
>
>> Yes, there's a draft PR 
>> with the Explainer's anticipated spec changes
>> ,
>> which are designed
>> 
>>  alike The rules for choosing a navigable
>> 
>> when a new top-level traversable
>> 
>> is being requested, as invoked by Window.open()
>> 
>> :
>>
>>- If currentNavigable's active window
>>
>> 
>>does not have transient activation
>>
>> 
>>and the user agent has been configured to not show popups (i.e., the user
>>agent has a "popup blocker" enabled)
>>   - The user agent may inform the user that a popup has been blocked.
>>
>>
>> On Thursday, May 9, 2024 at 7:30:09 AM UTC-7 Vladimir Levin wrote:
>>
>>> On Wed, May 8, 2024 at 7:46 PM Mike Wasserman  wrote:
>>>
 Contact emails

 m...@chromium.org, fugu-...@chromium.org

 Explainer


 https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture

 Specification

 https://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen

 Design docs


 https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture

 Summary

 A new "Automatic Fullscreen" content setting permits
 Element.requestFullscreen() without a user gesture, and permits browser
 dialogs to appear without exiting fullscreen.

 The setting is blocked by default and sites cannot prompt for
 permission. New UI controls are limited to Chrome's settings pages [1] and
 the site info bubble. Users can allow Isolated Web Apps [2], and enterprise
 admins can allow additional origins with the
 AutomaticFullscreenAllowedForUrls policy.

 Combined with Window Management permission [3] and unblocked popups
 [4], this unlocks valuable fullscreen capabilities:

 - Open a fullscreen popup on another display, from one gesture

 - Show fullscreen content on multiple displays from one gesture

 - Show fullscreen content on a new display, when it's connected

 - Swap fullscreen windows between displays with one gesture

 - Show fullscreen content after user gesture expiry or consumption

 [1] chrome://settings/content/automaticFullScreen and site details pages

 [2] User control is initially scoped to security-sensitive apps; see
 https://chromestatus.com/feature/5146307550248960

 [3] For multi-screen window placement features; see
 https://chromestatus.com/feature/5252960583942144

 [4] To similarly permit window.open() without a user gesture; see
 chrome://settings/content/popups

 Blink component

 Blink>Fullscreen
 

 Search tags

 Fullscreen ,
 requestFullscreen
 , transient
 activation
 , user
 gesture , content
 setting 

 TAG review

 N/A. This is not proposing a new or changed web API, but a
 browser-specific permission configuration.

>>>
>>> Does this change also need to update the referenced spec? In the spec,
>>> it seems like if there is no transient activation, it results in an error.
>>> I'm trying to understand whether (and how) the spec needs to be updated to
>>> reflect the capability proposed in this intent
>>>
>>>
 RisksInteroperability and Compatibility

 Element

Re: [blink-dev] Intent to Ship: Automatic Fullscreen Content Setting

[Vladimir Levin]

Ah thanks, I missed it in the explainer. The spec changes make sense to me.
The changes don't look like they would be controversial, but it's probably
worthwhile to ensure that this PR is under review and/or landing as a part
of shipping this.

Thanks!
Vlad

On Thu, May 9, 2024 at 12:20 PM Mike Wasserman  wrote:

> Yes, there's a draft PR 
> with the Explainer's anticipated spec changes
> ,
> which are designed
> 
>  alike The rules for choosing a navigable
> 
> when a new top-level traversable
> 
> is being requested, as invoked by Window.open()
> 
> :
>
>- If currentNavigable's active window
>
>does not have transient activation
>
> 
>and the user agent has been configured to not show popups (i.e., the user
>agent has a "popup blocker" enabled)
>   - The user agent may inform the user that a popup has been blocked.
>
>
> On Thursday, May 9, 2024 at 7:30:09 AM UTC-7 Vladimir Levin wrote:
>
>> On Wed, May 8, 2024 at 7:46 PM Mike Wasserman  wrote:
>>
>>> Contact emails
>>>
>>> m...@chromium.org, fugu-...@chromium.org
>>>
>>> Explainer
>>>
>>>
>>> https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture
>>>
>>> Specification
>>>
>>> https://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen
>>>
>>> Design docs
>>>
>>>
>>> https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture
>>>
>>> Summary
>>>
>>> A new "Automatic Fullscreen" content setting permits
>>> Element.requestFullscreen() without a user gesture, and permits browser
>>> dialogs to appear without exiting fullscreen.
>>>
>>> The setting is blocked by default and sites cannot prompt for
>>> permission. New UI controls are limited to Chrome's settings pages [1] and
>>> the site info bubble. Users can allow Isolated Web Apps [2], and enterprise
>>> admins can allow additional origins with the
>>> AutomaticFullscreenAllowedForUrls policy.
>>>
>>> Combined with Window Management permission [3] and unblocked popups [4],
>>> this unlocks valuable fullscreen capabilities:
>>>
>>> - Open a fullscreen popup on another display, from one gesture
>>>
>>> - Show fullscreen content on multiple displays from one gesture
>>>
>>> - Show fullscreen content on a new display, when it's connected
>>>
>>> - Swap fullscreen windows between displays with one gesture
>>>
>>> - Show fullscreen content after user gesture expiry or consumption
>>>
>>> [1] chrome://settings/content/automaticFullScreen and site details pages
>>>
>>> [2] User control is initially scoped to security-sensitive apps; see
>>> https://chromestatus.com/feature/5146307550248960
>>>
>>> [3] For multi-screen window placement features; see
>>> https://chromestatus.com/feature/5252960583942144
>>>
>>> [4] To similarly permit window.open() without a user gesture; see
>>> chrome://settings/content/popups
>>>
>>> Blink component
>>>
>>> Blink>Fullscreen
>>> 
>>>
>>> Search tags
>>>
>>> Fullscreen ,
>>> requestFullscreen
>>> , transient
>>> activation
>>> , user
>>> gesture , content
>>> setting 
>>>
>>> TAG review
>>>
>>> N/A. This is not proposing a new or changed web API, but a
>>> browser-specific permission configuration.
>>>
>>
>> Does this change also need to update the referenced spec? In the spec, it
>> seems like if there is no transient activation, it results in an error. I'm
>> trying to understand whether (and how) the spec needs to be updated to
>> reflect the capability proposed in this intent
>>
>>
>>> RisksInteroperability and Compatibility
>>>
>>> Element.requestFullscreen() may now succeed instead of rejecting without
>>> transient activation. The design doc considers some nuanced windowing
>>> corner cases. This feature is initially only available to
>>> security-sensitive apps and enterprise allow-listed origins.
>>>
>>> Gecko: No signal (
>>> https://github.com/mozilla/standards-positions/issues/1020)
>>>
>>> WebKit: No signal (
>>> https://github.com/WebKit/standards-positions/issues/345)
>>>
>>> W

Re: [blink-dev] Intent to Ship: Automatic Fullscreen Content Setting

[Mike Wasserman]

Yes, there's a draft PR  
with the Explainer's anticipated spec changes 
,
 
which are designed 

 alike The rules for choosing a navigable 

 
when a new top-level traversable 

 
is being requested, as invoked by Window.open() 
:

   - If currentNavigable's active window 
    
   does not have transient activation 
   
 
   and the user agent has been configured to not show popups (i.e., the user 
   agent has a "popup blocker" enabled)
  - The user agent may inform the user that a popup has been blocked.
   

On Thursday, May 9, 2024 at 7:30:09 AM UTC-7 Vladimir Levin wrote:

> On Wed, May 8, 2024 at 7:46 PM Mike Wasserman  wrote:
>
>> Contact emails
>>
>> m...@chromium.org, fugu-...@chromium.org
>>
>> Explainer
>>
>>
>> https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture
>>
>> Specification
>>
>> https://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen
>>
>> Design docs
>>
>>
>> https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture
>>
>> Summary
>>
>> A new "Automatic Fullscreen" content setting permits 
>> Element.requestFullscreen() without a user gesture, and permits browser 
>> dialogs to appear without exiting fullscreen.
>>
>> The setting is blocked by default and sites cannot prompt for permission. 
>> New UI controls are limited to Chrome's settings pages [1] and the site 
>> info bubble. Users can allow Isolated Web Apps [2], and enterprise admins 
>> can allow additional origins with the AutomaticFullscreenAllowedForUrls 
>> policy.
>>
>> Combined with Window Management permission [3] and unblocked popups [4], 
>> this unlocks valuable fullscreen capabilities:
>>
>> - Open a fullscreen popup on another display, from one gesture
>>
>> - Show fullscreen content on multiple displays from one gesture
>>
>> - Show fullscreen content on a new display, when it's connected
>>
>> - Swap fullscreen windows between displays with one gesture
>>
>> - Show fullscreen content after user gesture expiry or consumption
>>
>> [1] chrome://settings/content/automaticFullScreen and site details pages
>>
>> [2] User control is initially scoped to security-sensitive apps; see 
>> https://chromestatus.com/feature/5146307550248960
>>
>> [3] For multi-screen window placement features; see 
>> https://chromestatus.com/feature/5252960583942144
>>
>> [4] To similarly permit window.open() without a user gesture; see 
>> chrome://settings/content/popups
>>
>> Blink component
>>
>> Blink>Fullscreen 
>> 
>>
>> Search tags
>>
>> Fullscreen , 
>> requestFullscreen 
>> , transient 
>> activation 
>> , user 
>> gesture , content 
>> setting 
>>
>> TAG review
>>
>> N/A. This is not proposing a new or changed web API, but a 
>> browser-specific permission configuration.
>>
>
> Does this change also need to update the referenced spec? In the spec, it 
> seems like if there is no transient activation, it results in an error. I'm 
> trying to understand whether (and how) the spec needs to be updated to 
> reflect the capability proposed in this intent
>
>
>> RisksInteroperability and Compatibility
>>
>> Element.requestFullscreen() may now succeed instead of rejecting without 
>> transient activation. The design doc considers some nuanced windowing 
>> corner cases. This feature is initially only available to 
>> security-sensitive apps and enterprise allow-listed origins.
>>
>> Gecko: No signal (
>> https://github.com/mozilla/standards-positions/issues/1020)
>>
>> WebKit: No signal (
>> https://github.com/WebKit/standards-positions/issues/345)
>>
>> Web developers: Positive. Requested by 1st and 3rd party partners, 
>> particularly around VDI: 
>> https://github.com/w3c/window-management/issues/7 
>> https://github.com/w3c/window-management/issues/98 
>> https://github.com/w3c/window-management/issues/92 
>> https://crbug.com/315859364
>>
>> Ergonomics
>>
>> The explainer discusses prospective feature detection support.
>>
>> Activation
>>
>> Users or admins

Re: [blink-dev] Intent to Ship: Automatic Fullscreen Content Setting

[Vladimir Levin]

On Wed, May 8, 2024 at 7:46 PM Mike Wasserman  wrote:

> Contact emails
>
> m...@chromium.org, fugu-...@chromium.org
>
> Explainer
>
> https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture
>
> Specification
>
> https://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen
>
> Design docs
>
> https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture
>
> Summary
>
> A new "Automatic Fullscreen" content setting permits
> Element.requestFullscreen() without a user gesture, and permits browser
> dialogs to appear without exiting fullscreen.
>
> The setting is blocked by default and sites cannot prompt for permission.
> New UI controls are limited to Chrome's settings pages [1] and the site
> info bubble. Users can allow Isolated Web Apps [2], and enterprise admins
> can allow additional origins with the AutomaticFullscreenAllowedForUrls
> policy.
>
> Combined with Window Management permission [3] and unblocked popups [4],
> this unlocks valuable fullscreen capabilities:
>
> - Open a fullscreen popup on another display, from one gesture
>
> - Show fullscreen content on multiple displays from one gesture
>
> - Show fullscreen content on a new display, when it's connected
>
> - Swap fullscreen windows between displays with one gesture
>
> - Show fullscreen content after user gesture expiry or consumption
>
> [1] chrome://settings/content/automaticFullScreen and site details pages
>
> [2] User control is initially scoped to security-sensitive apps; see
> https://chromestatus.com/feature/5146307550248960
>
> [3] For multi-screen window placement features; see
> https://chromestatus.com/feature/5252960583942144
>
> [4] To similarly permit window.open() without a user gesture; see
> chrome://settings/content/popups
>
> Blink component
>
> Blink>Fullscreen
> 
>
> Search tags
>
> Fullscreen ,
> requestFullscreen
> , transient
> activation ,
> user gesture , content
> setting 
>
> TAG review
>
> N/A. This is not proposing a new or changed web API, but a
> browser-specific permission configuration.
>

Does this change also need to update the referenced spec? In the spec, it
seems like if there is no transient activation, it results in an error. I'm
trying to understand whether (and how) the spec needs to be updated to
reflect the capability proposed in this intent


> RisksInteroperability and Compatibility
>
> Element.requestFullscreen() may now succeed instead of rejecting without
> transient activation. The design doc considers some nuanced windowing
> corner cases. This feature is initially only available to
> security-sensitive apps and enterprise allow-listed origins.
>
> Gecko: No signal (
> https://github.com/mozilla/standards-positions/issues/1020)
>
> WebKit: No signal (
> https://github.com/WebKit/standards-positions/issues/345)
>
> Web developers: Positive. Requested by 1st and 3rd party partners,
> particularly around VDI: https://github.com/w3c/window-management/issues/7
> https://github.com/w3c/window-management/issues/98
> https://github.com/w3c/window-management/issues/92
> https://crbug.com/315859364
>
> Ergonomics
>
> The explainer discusses prospective feature detection support.
>
> Activation
>
> Users or admins must grant the new Automatic Fullscreen content setting,
> plus the Popups & Redirects content setting and the Window Management
> permission, and to take full advantage of fullscreen windowing features.
>
> Security
>
> This capability exacerbates preexisting fullscreen usable security
> concerns, so sites cannot show a permission prompt, and user controls are
> initially scoped to IWA contexts.
>
> WebView application risks
>
> None; this feature is not supported on WebView for now
>
> Debuggability
>
> Sites can debug via Element.requestFullscreen()'s promise, which may
> reject with a TypeError containing a message, the document
> `fullscreenElement` property, document `fullscreenchange` +
> `fullscreenerror` events, and devtools console messages. Transient
> activation state is exposed via navigator.userActivation.isActive. Script
> can check the window.location.href's scheme for `isolated-app:` to assess
> initial availability of user control for the current context.
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, ChromeOS, Android, and Android WebView)?
>
> No; Initial support targets desktop platforms.
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> No; WPT coverage is not yet available, and necessitates test driver
> controls for this new 

[blink-dev] Intent to Ship: Automatic Fullscreen Content Setting

[Mike Wasserman]

Contact emails

m...@chromium.org, fugu-...@chromium.org

Explainer

https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture

Specification

https://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen

Design docs

https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture

Summary

A new "Automatic Fullscreen" content setting permits
Element.requestFullscreen() without a user gesture, and permits browser
dialogs to appear without exiting fullscreen.

The setting is blocked by default and sites cannot prompt for permission.
New UI controls are limited to Chrome's settings pages [1] and the site
info bubble. Users can allow Isolated Web Apps [2], and enterprise admins
can allow additional origins with the AutomaticFullscreenAllowedForUrls
policy.

Combined with Window Management permission [3] and unblocked popups [4],
this unlocks valuable fullscreen capabilities:

- Open a fullscreen popup on another display, from one gesture

- Show fullscreen content on multiple displays from one gesture

- Show fullscreen content on a new display, when it's connected

- Swap fullscreen windows between displays with one gesture

- Show fullscreen content after user gesture expiry or consumption

[1] chrome://settings/content/automaticFullScreen and site details pages

[2] User control is initially scoped to security-sensitive apps; see
https://chromestatus.com/feature/5146307550248960

[3] For multi-screen window placement features; see
https://chromestatus.com/feature/5252960583942144

[4] To similarly permit window.open() without a user gesture; see
chrome://settings/content/popups

Blink component

Blink>Fullscreen


Search tags

Fullscreen ,
requestFullscreen ,
transient activation
, user
gesture , content
setting 

TAG review

N/A. This is not proposing a new or changed web API, but a browser-specific
permission configuration.

RisksInteroperability and Compatibility

Element.requestFullscreen() may now succeed instead of rejecting without
transient activation. The design doc considers some nuanced windowing
corner cases. This feature is initially only available to
security-sensitive apps and enterprise allow-listed origins.

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

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

Web developers: Positive. Requested by 1st and 3rd party partners,
particularly around VDI: https://github.com/w3c/window-management/issues/7
https://github.com/w3c/window-management/issues/98
https://github.com/w3c/window-management/issues/92
https://crbug.com/315859364

Ergonomics

The explainer discusses prospective feature detection support.

Activation

Users or admins must grant the new Automatic Fullscreen content setting,
plus the Popups & Redirects content setting and the Window Management
permission, and to take full advantage of fullscreen windowing features.

Security

This capability exacerbates preexisting fullscreen usable security
concerns, so sites cannot show a permission prompt, and user controls are
initially scoped to IWA contexts.

WebView application risks

None; this feature is not supported on WebView for now

Debuggability

Sites can debug via Element.requestFullscreen()'s promise, which may reject
with a TypeError containing a message, the document `fullscreenElement`
property, document `fullscreenchange` + `fullscreenerror` events, and
devtools console messages. Transient activation state is exposed via
navigator.userActivation.isActive. Script can check the
window.location.href's scheme for `isolated-app:` to assess initial
availability of user control for the current context.

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

No; Initial support targets desktop platforms.

Is this feature fully tested by web-platform-tests

?

No; WPT coverage is not yet available, and necessitates test driver
controls for this new content setting.

DevTrial instructions

https://github.com/explainers-by-googlers/html-fullscreen-without-a-gesture/blob/main/HOWTO.md

Flag name on chrome://flags

chrome://flags/#automatic-fullscreen-content-setting

Finch feature name

AutomaticFullscreenContentSetting

Requires code in //chrome?

True (Chrome settings pages, page info bubble, enterprise policy
integration)

Tracking bug

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

Launch bug

https://launch.corp.google.com/launch/4296344

Measurement

Blink.UseCoun