Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upSet navigation start value according to navigation timing spec #17735
Conversation
highfive
commented
Jul 14, 2017
|
Heads up! This PR modifies the following files:
|
highfive
commented
Jul 14, 2017
|
r? @jdm |
|
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. |
|
|
|
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.
This comment has been minimized.
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.
This comment has been minimized.
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.
This comment has been minimized.
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.
This comment has been minimized.
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.
|
r? @jdm |
|
r? @jdm |
|
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.
This comment has been minimized.
|
@bors-servo r=jdm |
|
|
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 -->
|
|
ferjm commentedJul 14, 2017
•
edited by larsbergstrom
./mach build -ddoes not report any errors./mach test-tidydoes not report any errorsThis change is