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.

Sign up for GitHub

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

Jump to bottom

Add environment's execution ready flag #1992

Closed
jungkees opened this issue Oct 28, 2016 · 3 comments
Closed

Add environment's execution ready flag #1992

jungkees opened this issue Oct 28, 2016 · 3 comments

Comments

@jungkees
Copy link
Contributor

jungkees commented Oct 28, 2016 •
edited
Loading

While working on SW's clients methods, I encountered additional requirements on the environment definition.

  • Environment's execution ready flag (initially false)
    • SW wants to expose a boolean client.reserved attribute (initially true when client is created)
      • Set to false when global/realm/environment settings object are created and the main resource is fetched (except initial browsing context creation)
      • True, otherwise
    • Given that, I plan to add this internal slot and set it in places where the environment settings object is created and the main resource is fetched
    • It'll be even better if we can sense those conditions without adding a flag, but I couldn't have found them yet (we need to consider both navigation and worker creation cases)
      - Environment's origin algorithm
      - SW methods check the reserved client's origin (to compare it against the running SW's origin.) Here the reserved client can be either an environment or an environment settings object. If the reserved client is an environment, the steps should use environment's creation URL's origin while they could simply use the origin with an environment settings object. So, the steps need to branch for them as of now. It'd be handy If we define an algorithm, origin, (for an environment) which returns its creation URL's origin under the assumption that the model supports some polymorphic dynamic dispatch based on which object's origin algorithm is called. Would it work?

I'll make a PR based on the discussion here.
@annevk
Copy link
Member

annevk commented Oct 28, 2016

Hmm, for origin, what if it turns out to be sandboxed in some way?

@jungkees
Copy link
Contributor Author

jungkees commented Oct 28, 2016 •
edited
Loading

An environment's origin would not be exposed but just used during the navigation even before the global and the document are created. The purpose of using it is to check it against the SW's origin to filter out those not in the same origin in the first place.

In the case it turns out to be sandboxed, it's just set to an opaque origin as expected I guess.

jungkees added a commit to jungkees/html that referenced this issue Nov 2, 2016
@jungkees
Extend environment concept
5a1ef04 
- Add execution ready flag, which is set when the corresponding
environment settings object is created and the potential main resource
is fetched (in the case of an initial browsing context creation, the
main resource fetch doesn't occur and not considered as a condition.)
 . This flag is mainly used in Service Worker's Client API (i.e. to
 get a value for client.reserved)
- Define the origin algorithm that returns the creation URL's origin
 . The origin algorithms defined in the environment settings objects
 override the behavior.
 . The primary purpose of defining this algorithm is to allow a
 polymorphic dispatch depending on the type of objects (i.e. to
 simplify the steps in the call sites.)

Related issue: whatwg#1992
@jungkees jungkees mentioned this issue Nov 2, 2016
Merged
@jungkees jungkees changed the title Additional features are needed on the environment Add environment's execution ready flag Nov 9, 2016
@jungkees
Copy link
Contributor Author

jungkees commented Nov 9, 2016

The proposed origin algorithm has been out of scope: #2004 (comment) Service worker spec has added the relevant origin algorithm: w3c/ServiceWorker@c4c1250

@annevk annevk closed this as completed in d358c78 Nov 9, 2016
alice pushed a commit to alice/html that referenced this issue Jan 8, 2019
@jungkees
Add environment's execution ready flag
e231c1d 
Service worker's Client's reserved attribute and clients.matchAll(/* options.includeReserved */) method require getting the state of a Client object whether its environment is in reserved state or not.

This commit adds the execution ready flag to the environment concept that distinguishes the state between before and after the user agent is ready to parse a fetched (or given default) document or execute a worker script.

The execution ready flag is set when the global object and realm execution context are created and the main resource (for parsing/executing) is ready.

Related service worker issue: w3c/ServiceWorker#1003.

Fixes whatwg#1992.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@jungkees @annevk