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

4.1 Processing model should rely on Fetch/HTML #136

Closed
26 tasks done
yoavweiss opened this issue Jan 19, 2021 · 3 comments
Closed
26 tasks done

4.1 Processing model should rely on Fetch/HTML #136

yoavweiss opened this issue Jan 19, 2021 · 3 comments
Labels
fetch-integration

Comments

@yoavweiss
Copy link
Contributor

yoavweiss commented Jan 19, 2021 •
edited by noamr
Loading

  • "if the navigation is aborted" section is vague. It should be based on precise flags from HTML/Fetch, rather than "aborted due", "caused by", etc.
  • Regarding the navigation type, it'd be better to refer to a specific Document object rather than "the navigation" and tie the "history handling behavior" in HTML to the former
  • "if there are no redirects" is not a precise term. A precise counter from Fetch should be used instead.
  • "same origin check" algorithm should be provided with the previous and current document/origin as input
  • The following should be tied to the Fetch/HTML processing model, instead of the current handwavy definition
    • unloadEventStart
    • unloadEventEnd
    • workerStart
    • fetchStart
  • The following should be inherited from Resource Timing (with some care around the differences between TAO and same origin checks)
    • domainLookupStart
    • domainLookupEnd
    • [ ]connectStart
    • connectEnd
    • nextHopProtocol
    • secureConnectionStart
    • requestStart
    • responseStart
    • responseEnd
    • transferSize
    • encodedBodySize
    • decodedBodySize
  • Step 20 redirect counts should be done as part of Fetch
  • The following should be done as part of HTML's processing model
    • domInteractive
    • domContentLoadedEventStart
    • domContentLoadedEventEnd
    • domComplete
    • loadEventStart
    • loadEventEnd
noamr added a commit to noamr/html that referenced this issue Mar 24, 2021
@noamr
WIP: Navigation Timing integration
ddf2b32 
Create a "document load timing info" struct, associated with
a document, which receives its information from several sources:
- fetch timing of the navigation response
- Load/DOMContentLoaded event dispatches
- Document readyness state changes
- sending unload events to the previous document, if it comes from the
  same origin.

See w3c/navigation-timing#136
Depends on whatwg/fetch#1185
noamr added a commit to noamr/html that referenced this issue Mar 25, 2021
@noamr
WIP: Navigation Timing integration
dd7ed70 
Create a "document load timing info" struct, associated with
a document, which receives its information from several sources:
- fetch timing of the navigation response
- Load/DOMContentLoaded event dispatches
- Document readyness state changes
- sending unload events to the previous document, if it comes from the
  same origin.

See w3c/navigation-timing#136
Depends on whatwg/fetch#1185
@noamr noamr mentioned this issue Mar 28, 2021
Merged
noamr added a commit to noamr/ServiceWorker that referenced this issue Mar 28, 2021
@noamr
Maintain timing for worker start/ready, for navigation requests.
4c00c07 
The timing when worker is started or ready are web-accessible via
the navigation timing API (https://w3c.github.io/navigation-timing/).

`workerStart` is specified to be the time when the service worker is run.

In Chromium and Gecko, `worker ready time` (exposed as `fetchStart`)
is set to the right before the time when the Fetch event can be
dispatched for the newly created worker.

In preparation for w3c/navigation-timing#136
@noamr noamr mentioned this issue Mar 28, 2021
Merged
@noamr
Copy link
Contributor

noamr commented Mar 29, 2021

  • "if the navigation is aborted" section is vague. It should be based on precise flags from HTML/Fetch, rather than "aborted due", "caused by", etc.

  • Regarding the navigation type, it'd be better to refer to a specific Document object rather than "the navigation" and tie the "history handling behavior" in HTML to the former

  • "if there are no redirects" is not a precise term. A precise counter from Fetch should be used instead.

  • "same origin check" algorithm should be provided with the previous and current document/origin as input

  • The following should be tied to the Fetch/HTML processing model, instead of the current handwavy definition

    • unloadEventStart
    • unloadEventEnd
    • workerStart
    • fetchStart

  • The following should be inherited from Resource Timing (with some care around the differences between TAO and same origin checks)

    • domainLookupStart
    • domainLookupEnd
    • [ ]connectStart
    • connectEnd
    • nextHopProtocol
    • secureConnectionStart
    • requestStart
    • responseStart
    • responseEnd
    • transferSize
    • encodedBodySize
    • decodedBodySize

  • Step 20 redirect counts should be done as part of Fetch

  • The following should be done as part of HTML's processing model

    • domInteractive
    • domContentLoadedEventStart
    • domContentLoadedEventEnd
    • domComplete
    • loadEventStart
    • loadEventEnd

All of the above are handled by whatwg/html#6536, once they're also integrated with Navigation Timing.

noamr added a commit that referenced this issue Mar 29, 2021
@noamr
Integration with the HTML spec
4a013a2 
Expose timing values measured in the HTML spec for the different
navigation timing values, instead of defining its o own processing model.
Depends on whatwg/html#6536
See #136
@noamr noamr mentioned this issue Mar 29, 2021
Merged
noamr added a commit to noamr/html that referenced this issue Apr 7, 2021
@noamr
WIP: Navigation Timing integration
8cf2e3e 
Create a "document load timing info" struct, associated with
a document, which receives its information from several sources:
- fetch timing of the navigation response
- Load/DOMContentLoaded event dispatches
- Document readyness state changes
- sending unload events to the previous document, if it comes from the
  same origin.

See w3c/navigation-timing#136
Depends on whatwg/fetch#1185
domenic pushed a commit to whatwg/html that referenced this issue Apr 7, 2021
@noamr
Navigation Timing integration
d799c4c 
Creates "document load timing info" and "document unload timing info" structs which get populated at appropriate points in the navigation and loading algorithms, and eventually handed to the appropriate Navigation Timing algorithms.

See w3c/navigation-timing#136 and w3c/navigation-timing#141.
yoavweiss pushed a commit that referenced this issue Apr 8, 2021
@noamr
Integration with the HTML spec (#141)
20af1c7 
* Integration with the HTML spec

Expose timing values measured in the HTML spec for the different
navigation timing values, instead of defining its o own processing model.
Depends on whatwg/html#6536
See #136

* Export add/enqueue navigation timing

* nit

* Apply latest HTML changes

* nits

* Add myself as an editor

* initiatorType is 'navigation' and not 'document'

* Fix refs
@noamr
Copy link
Contributor

noamr commented Apr 8, 2021 •
edited
Loading

  • "if the navigation is aborted" section is vague. It should be based on precise flags from HTML/Fetch, rather than "aborted due", "caused by", etc.

  • Regarding the navigation type, it'd be better to refer to a specific Document object rather than "the navigation" and tie the "history handling behavior" in HTML to the former

  • "if there are no redirects" is not a precise term. A precise counter from Fetch should be used instead.

  • "same origin check" algorithm should be provided with the previous and current document/origin as input

  • The following should be tied to the Fetch/HTML processing model, instead of the current handwavy definition

    • unloadEventStart
    • unloadEventEnd
    • workerStart

This one is still pending. See w3c/ServiceWorker#1575

  • fetchStart

  • The following should be inherited from Resource Timing (with some care around the differences between TAO and same origin checks)

    • domainLookupStart
    • domainLookupEnd
    • [ ]connectStart
    • connectEnd
    • nextHopProtocol
    • secureConnectionStart
    • requestStart
    • responseStart
    • responseEnd
    • transferSize
    • encodedBodySize
    • decodedBodySize

  • Step 20 redirect counts should be done as part of Fetch

  • The following should be done as part of HTML's processing model

    • domInteractive
    • domContentLoadedEventStart
    • domContentLoadedEventEnd
    • domComplete
    • loadEventStart
    • loadEventEnd

These are now resolved.

noamr added a commit to noamr/ServiceWorker that referenced this issue Apr 27, 2021
@noamr
Maintain timing for worker start/ready, for navigation requests.
b6de9fe 
The timing when worker is started or ready are web-accessible via
the navigation timing API (https://w3c.github.io/navigation-timing/).

`workerStart` is specified to be the time when the service worker is run.

In Chromium and Gecko, `worker ready time` (exposed as `fetchStart`)
is set to the right before the time when the Fetch event can be
dispatched for the newly created worker.

In preparation for w3c/navigation-timing#136
noamr added a commit to noamr/ServiceWorker that referenced this issue May 11, 2021
@noamr
Maintain timing for worker start/ready, for navigation requests.
d1c3f2e 
The timing when worker is started or ready are web-accessible via
the navigation timing API (https://w3c.github.io/navigation-timing/).

`workerStart` is specified to be the time when the service worker is run.

In Chromium and Gecko, `worker ready time` (exposed as `fetchStart`)
is set to the right before the time when the Fetch event can be
dispatched for the newly created worker.

In preparation for w3c/navigation-timing#136
jakearchibald pushed a commit to w3c/ServiceWorker that referenced this issue May 13, 2021
@noamr
Maintain timing for worker start/ready, for navigation requests. (#1575)
4b5d041 
* Maintain timing for worker start/ready, for navigation requests.

The timing when worker is started or ready are web-accessible via
the navigation timing API (https://w3c.github.io/navigation-timing/).

`workerStart` is specified to be the time when the service worker is run.

In Chromium and Gecko, `worker ready time` (exposed as `fetchStart`)
is set to the right before the time when the Fetch event can be
dispatched for the newly created worker.

In preparation for w3c/navigation-timing#136
@noamr
Copy link
Contributor

noamr commented May 20, 2021

I think this can be closed once whatwg/html#6670 is in.

@noamr noamr closed this as completed Nov 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
fetch-integration
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@noamr @yoavweiss