Possible confusion around history traversal queue and task source

[gterzian]

The Spec contains two concepts:

• A session-history-traversal-queue,
• A history-traversal-task-source

When working on something related to these two concepts, I initially thought that the "history-traversal-task-source" is the task-source used to enqueue tasks on the session-history-traversal-queue.

Reading up more on it, I realized the "session-history-traversal-queue" relates to a separate session-history-event-loop which runs "in parallel" to a browsing context event-loop.

I also realized that the "history-traversal-task-source" is not a task-source used to enqueue tasks onto this parallel "session-history-traversal-queue", rather it is actually used to enqueue task on a regular browsing context event-loop. See for example Step 5 of traverse-the-history-by-a-delta.

It appears that enqueuing a task onto the "session-history-traversal-queue" is done "explicitly" in the spec, without referring to a task-source, for example at the beginning of "traverse-the-history-by-a-delta", which reads " the user agent must append a task to this top-level browsing context's session history traversal queue".

To remove opportunities for confusion in the future, I propose the following:

1. At history-traversal-task-source, change the wording to read "This task source is used to queue calls to browsing-context specific sub-steps of history.back() and similar algorithms running on a session history event loop".
2. At session-history-traversal-queue remove the references to concept-task, since the concept of a "task" described there appears mostly relevant for "tasks" running on an "event-loop" that isn't a "session history event loop".
   (for example, "concept-task" starts with the wording: "An event loop has one or more task queues.", whereas a "session history event loop" will never have more than one queue. A bit further down it contains the wording "Each event loop also has a performing a microtask checkpoint flag", which a "session history event loop" does not have).
3. Perhaps add a new "session history traversal task" concept, which could be used in the parts of the spec related to the "session-history-traversal-queue" instead of linking to concept-task?
4. Perhaps restructure such "substeps" of history algorithms, for example Step 5 of traverse-the-history-by-a-delta to "await a stable state" and then queue a task using the "history-traversal-task-source" to "run the synchronous section" of said algorithm?