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

JavaScript API general discussion #2

Open
domenic opened this issue Sep 3, 2020 · 2 comments
Open

JavaScript API general discussion #2

domenic opened this issue Sep 3, 2020 · 2 comments
Labels
enhancement New feature or request

Comments

@domenic
Copy link
Collaborator

domenic commented Sep 3, 2020

What is document.loadingMode? All we see is its type property, right?

Should we use a promise instead of the sync getter + change event pattern?

@jeremyroman
Copy link
Collaborator

This is a bit of an attribute of the generality. I think that the simpler use cases are probably best served by something like privacycg/storage-access#55, which is simply a promise.

My thinking here was to expressly expose what the current loading mode is, which matters more if this expands. For example, if we end up needing "network-isolated" and "fenced" as separate modes, you'd want to be able to distinguish them. And some of these might make sense to parameterize (for example, we might wish to expose the notion of being proxied in some way), so exposing a dictionary or interface rather than an enum makes this more extensible.

If we're going to have an underlying primitive of "you are in this loading mode [therefore permissions policy is restricted in these ways, therefore you shouldn't necessarily record an impression, therefore ...]" in the spec, it seems natural to me to expose that to the platform too.

@domenic
Copy link
Collaborator Author

domenic commented Oct 26, 2020

Summarizing some discussion from #5 (comment) :

We have a few paths we could go with a JS API for prerendering and other loading modes.

  • Super-minimal; no dedicated API. Maybe add a "prerender" mode to visibilityState, since per @bokan that seems web-compatible. (And it already has a change event.) But mostly people rely on purpose-specific APIs like permissions and storage access.

  • Minimal but extensible. That's what the current proposal, slightly modified by First draft of prerendering browsing context #5, is trying to do. It has a LoadingMode interface, which so far only has EventTarget / onchange and the type property, but could grow if we want it to. The main delta vs. super-minimal here is that it allows distinguishing things like prerender vs. uncredentialed-prerender directly, instead of relying on other APIs like hasStorageAccess().

  • Maximal, i.e. expose a bunch of useful data. (But, we don't know exactly what that is yet.)

@domenic domenic changed the title JavaScript API seems strange JavaScript API general discussion Oct 26, 2020
domenic added a commit that referenced this issue Dec 8, 2020
For now, the prerendering state API and other existing APIs should suffice. Related to #2.
domenic added a commit that referenced this issue Dec 8, 2020
For now, the prerendering state API and other existing APIs should suffice. Related to #2.
@jeremyroman jeremyroman added the enhancement New feature or request label Apr 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants