Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce "implicitly restricted APIs". #62

Merged
merged 2 commits into from
May 19, 2021
Merged

Conversation

mfalken
Copy link
Collaborator

@mfalken mfalken commented May 15, 2021

This expands "Activated-Gated APIs" to cover other reasons that an API
can be implicitly restricted, namely, if it requires system focus or
page visibility.

It also clarifies that prerendering browsing contexts never have system
focus or page visibility, as per discussion in #59 and #55.


Preview | Diff

This expands "Activated-Gated APIs" to cover other reasons that an API
can be implicitly restricted, namely, if it requires system focus or
page visibility.

It also clarifies that prerendering browsing contexts never have system
focus or page visibility, as per discussion in WICG#59 and WICG#55.
@mfalken
Copy link
Collaborator Author

mfalken commented May 15, 2021

@domenic can you review this? While writing this I noticed the discussion in #59 is opposite what the current spec says, so we can also continue discussion on #59 if you think it should be "visible".

Copy link
Collaborator

@domenic domenic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. I agree the existing text about "do not count as hidden" is wrong; maybe I was thinking of portals.


<h3 id="interaction-with-visibility-state">Interaction with Page Visibility</h3>

Documents in [=prerendering browsing contexts=] are [=Document/hidden=].
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that for portals this might not be true, and portals are envisioned to be a type of prerendering browsing context. We might want to state that subtlety here as a TODO or Note, even though portals spec work is kind of on hold while we get these foundations worked out...

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done, added it as an Issue which seemed consistent with the other Issues about portals.

index.bs Outdated
@@ -853,3 +870,9 @@ The following APIs do not need modifications, because they will automatically fa
- Firing of clipboard events, as well as {{Clipboard/read()|navigator.clipboard.read()}} and {{Clipboard/readText()|navigator.clipboard.readText()}} [[CLIPBOARD-APIS]]
- {{Navigator/share()|navigator.share()}} [[WEB-SHARE]]
- {{Element/requestPointerLock()|element.requestPointerLock()}} [[POINTERLOCK]]

APIs that require the [=Document/visible=] [=Document/visibility state=]:
- {{WakeLock/request()}} [[WAKE-LOCK]]
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- {{WakeLock/request()}} [[WAKE-LOCK]]
- {{WakeLock/request()|navigator.wakeLock.request()}} [[WAKE-LOCK]]

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I made this change, also reverted to [SCREEN-WAKE-LOCK] which I didn't realize the original spec had instead of [WAKE-LOCK]. I don't know what source code that comes from.

@mfalken
Copy link
Collaborator Author

mfalken commented May 18, 2021

Thanks, done! I added a commit though the diff still seems to show the old one. Would you be able to merge if it's ready? I don't have write access.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants