hashchange DOM event should be dispatched when the document location's hash is changed

[glennw]

1. Open https://lhorie.github.io/todomvc-perf-comparison/todomvc-benchmark/ in Servo.
2. Select "Run all"

The tests will start running. At some point during the benchmark, execution stops and nothing further happens. The rendering is still running (can be confirmed with -Z wr-stats).

Sometimes you get several JS errors written on the console - but this doesn't always happen.

For example:

Om,Adding50Items,expected,50,got,0
Om,CompletingAllItems,expected,50,got,0
ERROR:script::dom::bindings::error: Error at https://lhorie.github.io/todomvc-perf-comparison/todomvc-benchmark/todomvc/ractive/bower_components/ractive/Ractive.js:3:19921 Could not parse template: ...
							&lt;!-- The <- failed at character 1108 ->{{&gt;item}} partial...
ERROR:script::dom::bindings::error: Error at https://lhorie.github.io/todomvc-perf-comparison/todomvc-benchmark/todomvc/ractive/js/persistence.js:45:1 todoList is not defined
ERROR:script::dom::bindings::error: Error at https://lhorie.github.io/todomvc-perf-comparison/todomvc-benchmark/todomvc/ractive/js/routes.js:25:1 todoList is not defined

[glennw]

cc @jdm @metajack

[metajack]

cc @esprehn

[jdm]

I've observed this a few times after variable numbers of tests have completed. I suspect there's a timing issue that makes the harness get confused, rather than an internal engine problem like a deadlock.

[jdm]

The Mithril suite seems to trigger this most often when I run the tests in isolation.

[jdm]

Ractive triggered the JS errors for me.

[jdm]

Those both seem to be consistent for me, and it would explain the intermittent behaviour you observed - the order of the testsuites seems to be randomized every time I load the benchmark.

[jdm]

I filed #14975 for the Ractive problem.

[jdm]

The problem with the tests not continuing is due to the Mithril test suite, and that's caused by us missing the hashchange DOM event that it relies on for routing if window.history.pushState isn't available.

[jdm]

To reproduce easily, run an HTTP server inside todomvc-perf-comparison/todomvc-benchmark, and run ./mach run http://localhost:8000/todomvc/mithril/index.html.

[jdm]

@cbrewster The spec text for hashchange falls under steps 6 and 15 of https://html.spec.whatwg.org/multipage/browsers.html#traverse-the-history . Do we have an implementation of the "traverse the history" algorithm yet?

[cbrewster]

@jdm the "traverse the history" algorithm is found in the constellation:
https://dxr.mozilla.org/servo/rev/5d3847dddc9bb7907abfa5d38a7927d6c656fbc1/components/constellation/constellation.rs#1668-1702
and
https://dxr.mozilla.org/servo/rev/5d3847dddc9bb7907abfa5d38a7927d6c656fbc1/components/constellation/constellation.rs#1972-2082
It is a bit messy when aligning it to the spec as we have to split some logic between the constellation and script threads.
A new history entry will need to be added to a Frame each time the hash is changed and upon traversal we can tell the corresponding script thread to trigger the event.
Unfortunately, the current history logic assumes that each entry has a unique PipelineId from all other entries. With pushState/hash changes, we will have cases where multiple entries will have the same PipelineId. Some of this is handled in #13781, but I haven't had the time to finish that up yet.