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

Set navigation start value according to navigation timing spec #17735

Merged
merged 1 commit into from Jul 18, 2017

Conversation

@ferjm
Copy link
Member

ferjm commented Jul 14, 2017

  • ./mach build -d does not report any errors
  • ./mach test-tidy does not report any errors
  • These changes fix #17651

This change is Reviewable

@highfive
Copy link

highfive commented Jul 14, 2017

Heads up! This PR modifies the following files:

  • @asajeffrey: components/constellation/network_listener.rs, components/constellation/constellation.rs
  • @fitzgen: components/script/dom/document.rs, components/script/script_thread.rs, components/script/document_loader.rs, components/script/dom/eventsource.rs, components/script/dom/window.rs and 2 more
  • @KiChjang: components/script/dom/document.rs, components/net/fetch/methods.rs, components/net/resource_thread.rs, components/script/script_thread.rs, components/net_traits/lib.rs and 8 more
@highfive
Copy link

highfive commented Jul 14, 2017

warning Warning warning

  • These commits modify net and script code, but no tests are modified. Please consider adding a test!
@ferjm
Copy link
Member Author

ferjm commented Jul 14, 2017

r? @jdm

@highfive highfive assigned jdm and unassigned wafflespeanut Jul 14, 2017
@jdm
Copy link
Member

jdm commented Jul 14, 2017

This seems more complicated than necessary. The value for navigation start would make more sense as the time at which the fetch was initiated by the thread that communicates with the network thread, rather than the time at which the fetch algorithm starts executing on the network thread.

@bors-servo
Copy link
Contributor

bors-servo commented Jul 17, 2017

The latest upstream changes (presumably #16508) made this pull request unmergeable. Please resolve the merge conflicts.

@ferjm ferjm force-pushed the ferjm:navigationstart branch from 252ea27 to 75e953d Jul 17, 2017
@ferjm ferjm force-pushed the ferjm:navigationstart branch from 75e953d to c4c78da Jul 17, 2017
@ferjm
Copy link
Member Author

ferjm commented Jul 17, 2017

r? @jdm

@@ -181,6 +185,8 @@ impl InProgressLoad {
is_visible: true,
url: url,
origin: origin,
navigation_start: 0,
navigation_start_precise: 0.,

This comment has been minimized.

@jdm

jdm Jul 17, 2017

Member

Why don't we store the values here? No need to for any of the constellation to be aware of the timing code at all.

This comment has been minimized.

@ferjm

ferjm Jul 18, 2017

Author Member

I am not sure what you mean with storing the values here, they are already stored in InProgressLoad during the handling of the constellation message to script that notifies about the start of the navigation. Anyway, I agree that the constellation does not need to be aware of the timing code, so I am removing that part. Thanks!

This comment has been minimized.

@jdm

jdm Jul 18, 2017

Member

To rephrase my question - why don't we get the current time here and store it immediately, instead of waiting for the constellation? This both simplifies the code and gives us a more accurate initial time.

This comment has been minimized.

@ferjm

ferjm Jul 18, 2017

Author Member

Ok, thank you for rephrasing the question. I added the constellation code trying to address your suggestion of setting the navigation start time as the time at which the thread that communicates with the network thread initiates the fetch. Setting navigation start during InProgressLoad construction does not vary the value significantly, but it indeed simplifies the code, so I'll change it as you suggests. Thanks for the feedback and apologies for the back and forth.

@ferjm
Copy link
Member Author

ferjm commented Jul 18, 2017

r? @jdm

@ferjm ferjm force-pushed the ferjm:navigationstart branch from 5377b42 to 9ebf234 Jul 18, 2017
@ferjm
Copy link
Member Author

ferjm commented Jul 18, 2017

r? @jdm

@jdm
jdm approved these changes Jul 18, 2017
Copy link
Member

jdm left a comment

This looks fine with a simple change. Sorry my descriptions suggested more complexity than was necessary!

navigation_start: u64,
navigation_start_precise: f64,
navigation_start: DOMRefCell<u64>,
navigation_start_precise: DOMRefCell<f64>,

This comment has been minimized.

@jdm

jdm Jul 18, 2017

Member

These can be Cell instead.

@ferjm ferjm force-pushed the ferjm:navigationstart branch from 9ebf234 to db044bd Jul 18, 2017
@ferjm
Copy link
Member Author

ferjm commented Jul 18, 2017

@bors-servo r=jdm

@bors-servo
Copy link
Contributor

bors-servo commented Jul 18, 2017

📌 Commit db044bd has been approved by jdm

@bors-servo
Copy link
Contributor

bors-servo commented Jul 18, 2017

Testing commit db044bd with merge eb26194...

bors-servo added a commit that referenced this pull request Jul 18, 2017
Set navigation start value according to navigation timing spec

- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix #17651

<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/17735)
<!-- Reviewable:end -->
@bors-servo
Copy link
Contributor

bors-servo commented Jul 18, 2017

@bors-servo bors-servo merged commit db044bd into servo:master Jul 18, 2017
3 checks passed
3 checks passed
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

5 participants
You can’t perform that action at this time.