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

Define timeOrigin in the HTML spec #131

Closed
noamr opened this issue Nov 14, 2021 · 5 comments · Fixed by #132
Closed

Define timeOrigin in the HTML spec #131

noamr opened this issue Nov 14, 2021 · 5 comments · Fixed by #132

Comments

@noamr
Copy link
Contributor

noamr commented Nov 14, 2021

Instead of saying what timeOrigin means, set it explicitly in the HTML spec at the right moments.
@yoavweiss
Copy link
Contributor

Should we hang it off of the global object? environment settings object?

@noamr
Copy link
Contributor Author

noamr commented Nov 15, 2021

I'm working on a patch.
I believe it should be associated with a document and with a WorkerGlobalScope. Otherwise it would get fudged in BFCache (which is unspecified behavior today)

@noamr
Copy link
Contributor Author

noamr commented Nov 15, 2021

... problem is that during navigation time recording there is no document yet, so this would take some delicate handling

@noamr noamr mentioned this issue Nov 15, 2021
Closed
noamr added a commit to noamr/html that referenced this issue Nov 15, 2021
@noamr
Specify how timeOrigin is computed
57df614 
The time origin, which is the epoch for all performance timeline APIs,
was previously defined [here](https://w3c.github.io/hr-time/#dfn-time-origin).

This PR makes its computation explicity, without changing its current
definition and behavior.

- `time origin` becomes an `environment settings object` algorithm,
  computed differently for windows vs. worker scopes

- The 4 places where this timestamp is set are creation of an
`about:blank` context, beginning of navigation, confirmation of an
unload prompt, and creating a worker.

- The timestamp is a `shared monotonic clock` value, which is defined
in HR-TIME (and internally in ECMAScript).

As part of this PR, also refactored unload prompts to return a result
rather than rely on a somewhat hand-wavy "refused to allow" property.

See w3c/hr-time#131
and w3c/navigation-timing#166
@noamr noamr mentioned this issue Nov 15, 2021
Merged
3 tasks
noamr added a commit that referenced this issue Nov 15, 2021
@noamr
Remove own version of timeOrigin definition
6103713 
See whatwg/html#7339

`time origin` is now an `environment settings object` algorithm,
so the reference here should forward there.

Closes #131
@noamr noamr mentioned this issue Nov 15, 2021
Merged
4 tasks
@npm1
Copy link
Contributor

npm1 commented Nov 15, 2021

It should be Window or WorkerGlobalScope, no?

@noamr
Copy link
Contributor Author

noamr commented Nov 15, 2021

It should be Window or WorkerGlobalScope, no?

See the html PR. It's in the environment settings object, which is where the "virtual" things that can go to either a window or a worker but in a different way are defined.

noamr added a commit to noamr/html that referenced this issue Nov 22, 2021
@noamr
Specify how timeOrigin is computed
03c6a14 
The time origin, which is the epoch for all performance timeline APIs,
was previously defined [here](https://w3c.github.io/hr-time/#dfn-time-origin).

This PR makes its computation explicity, without changing its current
definition and behavior.

- `time origin` becomes an `environment settings object` algorithm,
  computed differently for windows vs. worker scopes

- The 4 places where this timestamp is set are creation of an
`about:blank` context, beginning of navigation, confirmation of an
unload prompt, and creating a worker.

- The timestamp is a `shared monotonic clock` value, which is defined
in HR-TIME (and internally in ECMAScript).

As part of this PR, also refactored unload prompts to return a result
rather than rely on a somewhat hand-wavy "refused to allow" property.

See w3c/hr-time#131
and w3c/navigation-timing#166
noamr added a commit to noamr/html that referenced this issue Nov 24, 2021
@noamr
Specify how timeOrigin is computed
c686e3a 
The time origin, which is the epoch for all performance timeline APIs,
was previously defined [here](https://w3c.github.io/hr-time/#dfn-time-origin).

This PR makes its computation explicity, without changing its current
definition and behavior.

- `time origin` becomes an `environment settings object` algorithm,
  computed differently for windows vs. worker scopes

- The 4 places where this timestamp is set are creation of an
`about:blank` context, beginning of navigation, confirmation of an
unload prompt, and creating a worker.

- The timestamp is a `shared monotonic clock` value, which is defined
in HR-TIME (and internally in ECMAScript).

As part of this PR, also refactored unload prompts to return a result
rather than rely on a somewhat hand-wavy "refused to allow" property.

See w3c/hr-time#131
and w3c/navigation-timing#166
domenic pushed a commit to whatwg/html that referenced this issue Nov 29, 2021
@noamr
Specify "time origin" computation
60c8bf6 
The time origin, which is the epoch for all performance timeline APIs, was previously defined in https://w3c.github.io/hr-time/#dfn-time-origin.

This makes its computation explicit, without changing its current definition and behavior. Notably:

* "time origin becomes an environment settings object algorithm, computed differently for windows vs. worker scopes.

* The 4 places where this timestamp is set are creation of an about:blank browsing context, the beginning of navigation, the confirmation of an unload prompt, and the creation of a worker.

* The timestamp is a "shared monotonic clock" value, which is defined in HR-TIME (and internally in ECMAScript).

As part of this PR, also refactored unload prompts to return a result rather than rely on a somewhat hand-wavy "refused to allow" property.

See w3c/hr-time#131 and w3c/navigation-timing#166. See also w3c/ServiceWorker#1621.
@noamr noamr closed this as completed in #132 Dec 1, 2021
noamr added a commit that referenced this issue Dec 1, 2021
@noamr
Remove own version of timeOrigin definition (#132)
20c8cc9 
* Remove own version of `timeOrigin` definition

See whatwg/html#7339

`time origin` is now an `environment settings object` algorithm,
so the reference here should forward there.

Closes #131

* Refactor and add note
mfreed7 pushed a commit to mfreed7/html that referenced this issue Jun 3, 2022
@noamr
Specify "time origin" computation
aecafc4 
The time origin, which is the epoch for all performance timeline APIs, was previously defined in https://w3c.github.io/hr-time/#dfn-time-origin.

This makes its computation explicit, without changing its current definition and behavior. Notably:

* "time origin becomes an environment settings object algorithm, computed differently for windows vs. worker scopes.

* The 4 places where this timestamp is set are creation of an about:blank browsing context, the beginning of navigation, the confirmation of an unload prompt, and the creation of a worker.

* The timestamp is a "shared monotonic clock" value, which is defined in HR-TIME (and internally in ECMAScript).

As part of this PR, also refactored unload prompts to return a result rather than rely on a somewhat hand-wavy "refused to allow" property.

See w3c/hr-time#131 and w3c/navigation-timing#166. See also w3c/ServiceWorker#1621.
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
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Remove own version of timeOrigin definition w3c/hr-time
3 participants
@noamr @yoavweiss @npm1