Storing notes ahead of merge

Author: jakearchibald

source

@@ -82975,32 +82975,47 @@ interface <dfn>BarProp</dfn> {
         </ol>
 
         <p class="note">This is only done for the <span>traversable navigable</span>, as all nested <span data-x="navigable">navigables</span> will be part of the same <span>browsing session</span>.</p>
+
+        JAKE-TODO: This seems wrong for cross-thread access.
        </li>
 
        JAKE-TODO: YOU ARE HERE - time to set the correct history entry and everything that comes with that.
-      </ol>
 
-      <p class="note">Steps are grouped into <span data-x="agent">agents</span> to avoid synchronously observable things being out of sync.</p>
+       <li><p>If <var>navigable</var>'s <span data-x="nav-current-history-entry">current session history entry</span> is <var>targetEntry</var>, then abort these steps.</p></li>
+
+       <li>
+        <p>If <var>navigable</var>'s <span data-x="nav-displayed-history-entry">displayed session history entry</span> is <var>targetEntry</var>, then set <var>navigable</var>'s <span data-x="nav-current-history-entry">current session history entry</span> to <var>targetEntry</var> and abort these steps.</p>
+
+        <p class="note">For example, if traversing back results in the <span data-x="nav-displayed-history-entry">displayed</span> and <span data-x="nav-current-history-entry">current</span> session history entries becoming out of sync (due to a 204 response), traversing forward would hit the case above where they become in sync again, but there's no further action to perform.</p>
+       </li>
+
+       YOU ARE HERE: spec the two phase approach, where we initially check if something is eligable for navigation before starting (allowed to navigate + unload prompts)
+
+       <li><p></p></li>
+      </ol>
      </li>
     </ol>
    </li>
 
    Map should be agent to (document, list of algorithm steps)
 
+   "Allowed to navigate" covers any kind of session history change
+    May go deep but only if document will remain the same
+   "Unload prompt" covers cases where document will change
+    If doc will change, fire event in that context and all others
+
+   Check allowed to navigate without posting tasks (can just look up current history entry) - there's a race here but who cares. Or do we need displayed entry??
+    current history entry is only ever set async
+   If not allowed, bail
    For each history entry list:
-    Post task to document: (TODO: coalese these to agents)
-     Update history length and indexes
-     If history items are the same, bail.
-     TODO: check for pending step
-     If doc states are not the same:
-      Discard etc etc
-     Set history item:
-      Scroll position etc etc
-    If the documents are the same between current and target:
-     Go through nested lists
-
-
-   TODO: also update history.length & indexes
+    Post task to document:
+     Update history length and index
+     If current history items are the same, continue.
+     Update current entry?? (or need to do this in parallel?)
+     If displayed history item needs changing, do that.
+     If that means changing docs, do the discarding stuff.
+
+
    TODO: on a second pass, incorporate https://html.spec.whatwg.org/#traverse-the-history
   </ol>