What should history.back() do when sync navigations are involved?

[domenic]

Consider the following scenario, due to @natechapin:

// start on index.html
location.hash = "#foo";
history.back();
location.hash = "#bar";

Where do you end up?

Apparently in Firefox you end up on index.html#foo and in Chrome you end up on index.html. Probably similar issues occur for history.pushState().

@jakearchibald, I suspect this has a more-correct answer in the framework you're working on... any thoughts on what it should be?

[jakearchibald]

In my current model:

1. History is ['index.html'] and current step is 0.
2. Synchronously update to index.html#foo, and queue TaskA to update the history tree.
3. Queue TaskB for back().
4. Synchronously update to index.html#bar, and queue TaskC to update the history tree.
5. TaskA (index.html#foo):
   1. Update history tree to ['index.html', 'index.html#foo'].
   2. index.html#foo is given a step of 1.
   3. Update current step to 1.
   4. Top level doesn't change, because its current active item index.html#bar has a 'pending' step (as in, the synchronous navigation hasn't been resolved).
6. TaskB (back()):
   1. Update current step to 0.
   2. Top level doesn't change, because its current active item index.html#bar has a 'pending' step (as in, the synchronous navigation hasn't been resolved).
7. TaskC (index.html#bar):
   1. Update history tree to ['index.html', 'index.html#bar'] (index.html#foo is removed by clearing forward history)
   2. index.html#bar is given a step of 1.
   3. Update current step to 1.
   4. Top level doesn't need to change, because it's already on index.html#bar.

I feel pretty good about that result (I know, I'm biased) as it's the same result as running those steps one by one. But ugh, if neither Chrome or Firefox do that, does that mean I should change it?

Fwiw, I wouldn't have guessed either the Chrome result or the Firefox result, I can't really make sense of it.

I wouldn't have been surprised if the history result was ['index.html', 'index.html#foo', 'index.html#bar'] because of the index.html#bar navigation aborting the back() traversal. I haven't looked much at aborting yet, but I'm hoping to limit that to navigations that require fetches.

[natechapin]

Fwiw, I wouldn't have guessed either the Chrome result or the Firefox result, I can't really make sense of it.

Chrome's step 1-5 are identical to your model, with the caveat that all queued tasks are IPCs. The difference starts at step 6:

6. TaskB (back()):

• Set 'pending' current step to 0.
• Queue TaskD (again, an IPC) to traverse to the joint session history entry at step 0.

7. TaskC (index.html#bar):

• Update history tree to ['index.html', 'index.html#foo', 'index.html#bar']
• index.html#bar is given a step of 2.
• Update current step to 2.

8. TaskD (back() continuation):

• Restore state for step 0
• Queue TaskE to update the history tree

9. TaskE (back() continuation):

• Update current step to 0.

If you care about the implementation details, Steps 1, 2, 3, 4, and 8 are in Chrome's renderer process, while Steps 5, 6, 7, and 9 are in the browser process.

[jakearchibald]

Do you feel Chrome's current result is correct by design, or a side-effect of the implementation?

[natechapin]

I think it's within the range of possible correct designs we could settle on. It's not clear to me how the bookkeeping would work for things like Step 5.iv in your algorithm, because the synchronous processing and the navigation resolution step are in different processes.

I think Chrome could probably get most of the way there if we could get rid of TaskE in my description and have TaskB not do a "pending" step and just immediately update the current step. I don't know whether that would cause unacceptable race conditions, though.

[annevk]

cc @smaug----

[smaug----]

Gecko's behavior makes the most sense to me. You just queue a task to do back(). Sync navigations behave from session history point of view as if they were, well, sync.
I'm a bit surprised of Chrome's behavior.

[jakearchibald]

Tasks need to be queued for sync navigations too, to update the history tree (which may be in another process) and things like history.length across all the frames.

Eg, if two iframes in different threads/processes perform sync navigations at the same time, one has to win. Although the document switch is synchronous, the updates to the history tree can't be synchronous without blocking IPCs or a racey mess.

[jakearchibald]

I guess I could hack it so that there are two queues instead of one. One for 'synchronous' navigations and another for the rest.

So:

1. History is ['index.html'] and current step is 0.
2. Synchronously update to index.html#foo, and queue TaskA into the 'sync navigation' queue to update the history tree.
3. Queue TaskB into the 'async navigation' queue for back().
4. Synchronously update to index.html#bar, and queue TaskC into the 'sync navigation' queue to update the history tree.
5. 'sync' queue is not empty, so TaskA (index.html#foo):
   1. Update history tree to ['index.html', 'index.html#foo'].
   2. index.html#foo is given a step of 1.
   3. Update current step to 1.
   4. Top level doesn't change, because its current active item index.html#bar has a 'pending' step (as in, the synchronous navigation hasn't been resolved).
6. 'sync' queue is not empty, so TaskC (index.html#bar):
   1. Update history tree to ['index.html', 'index.html#foo', 'index.html#bar']
   2. index.html#bar is given a step of 2.
   3. Update current step to 2.
   4. Top level doesn't need to change, because it's already on index.html#bar.
7. 'sync' queue is empty, so we go to the other queue for TaskB (back()):
   1. Update current step to 1.
   2. Top level changes to index.html#foo.

I still prefer the version I've currently spec'd where there's only one queue, but Firefox's result at least seems deliberate and not a side-effect.

[domenic]

Note that in the spec same-document (sync) navigations are supposed to empty any queued-up traversals: https://html.spec.whatwg.org/#navigate-fragid step 2 and https://html.spec.whatwg.org/#url-and-history-update-steps step 2.2.

Apparently no browsers do this, so that's fun.

[domenic]

Firefox behaves differently here for pushState() vs. fragment navigations:

history.pushState(null, "", "/foo");
history.back();
history.pushState(null, "", "/bar");

ends up on /bar instead of on /foo.

Chrome still ends up on index.html.

I'll write some tests that assume the Firefox behavior for fragments carry over to pushState(), even though nobody does that...

[smaug----]

In that testcase history.pushState() cancels .back() in Gecko.