Loading...

​​History traversal

​​GT: some of the changes in progress right now. Window::load_url was the entry point into navigating from script, which would send a message to the script thread and had this extra step that looked unnecessary. only the anchor element navigates with a task, and discovered unexpected behaviour changes when removing it. discovered that evaluating JS url in navigation is supposed to enqueue a task. led to doing things more explicitly as a result. in the same spirit, when you use the history API you can end up doing navigation. the spec acknowledges that the join session history work happens in parallel, then the spec says to enqueue a task on the relevant event loop. then do the history traversal algorithm on the script thread. proposing to rewrite some of that code more like spec.

​​

​​CB: with history api, you can specify how many history entries to traverse. you might end up updating multiple entries as a result. it’s hard to do this on a single script thread because it could affect multiple script threads.

​​

​​GT: so if you go back over multiple entries, do you modify all of them?

​​

​​CB: don’t want to fire multiple popstates.

​​

​​AJ: need to follow source pipeline and all its parents, and target pipeline and all its parents, so could be unbounded number of script threads.

​​

​​GT: based on if it’s cross origin?

​​

​​AJ: horror case is navigating one very deep iframe.

​​

​​CB: need to keep track of inactive, active, fully active. need to notify active ones that are now inactive.

​​

​​AJ: why we’re here is that the changes that implemented pushstate/popstate, the spec has changed since then. for the better, since it now reflects reality, and we caused that. part of that was us being pushy about it, and part of it was process isolation requirements made people look at session history again. one of the things you’re seeing is that there is not a perfect alignment between what we’re doing and what spec is doing. the old spec servo could not implement, so we did something kind of sort of like it. if we align to the new spec, it will be code cleanup and paying off tech debt, but wont’ give us any new support.

​​

​​GT: we do get a bunch of intermittents around history traversal.

​​

​​AJ: how difficult will it be to get rid of that? these things are in different processes, so there will be race conditions.

​​

​​GT: there are two parts to the spec - two algorithms. one of them happens in parallel, in the constellation for us, and the history traversal algorithm is the one that fires events. if you need to communicate with a bunch of script threads, we can do that from the constellation. a bunch of sequential steps, however, then we could turn them into tasks that are queued on history traversal task source.

​​

​​AJ: at least not going to make it worse!

​​

​​GT: if we identified the part that associates with one event loop, we could separate it from the cross-origin nightmare with lots of back and forth. my philosophy for the WPT tests is that sometimes you have lots of the tests passing but making the remainder pass…

​​

​​CB: has anybody looked at those intermittent failures? my experience is a bunch of those tests are timeout-based. also currently in servo we have a pending history entry that becomes active when the load is finished. but spec describes having a pending future entry and then navigate to it. this is something that might be incompatible.

​​

​​GT: I guess there’s no clear cut case for what we should do differently right now. we send a few messages at a time, and we could consolidate them. and there’s cancelling any tasks on the history task source, right now we don’t use it so we can’t really cancel…

​​

​​AJ: if you got a traversal and before it was finished you got another traversal. do we need to notify the intermediate stories.

​​

​​GT: looks like it.

​​

​​CB: yeah, didn’t think about cancellation for traversal at all. traversal’s pretty quick…

​​

​​AJ: unless you need to reload the document…

​​

​​JM: given how important docuemnt loading and sessio nhistory is to loading any webpage, matching our code against the spec would be valuable to understand the complexity.

​​

​​AJ: might help understand the spec. we would probably be the first people to try implementing that new spec.

​​

​​JM: yes, but good to have clear work items like we’ve discussed.

​​

​​AJ: I probably will have time to review changes, but not necessarily do the changes.

​​

​​CB: one other thing, scroll state restoration was never implemented.