duhrer
commented
5 months ago Sadly, the chrome extension methods don't help with the underlying problem. The history search they provide cannot be limited to the current tab, so you can't come up with an easy list of history states that match window.history. Without that, you can't determine the position. I will clean up the work in process, which improves other things, and commit that somehow.
In client-side javascript code, you can see how many pages there are in history, but not where we are in history. This limits our ability to tell when we're already at the beginning or end of history.
With a chrome extension, you actually have the option to look at the full list of items in history. With that, we can compare the current window's URL to determine where in history the current page is.
If the user has navigated to the same page twice, we can use the "last visited" date to disambiguate, i.e. the one with the latest date is by definition the active page.
Currently, we separate out the background-facing actions and those that use pure client-side code. Even though the action may never end up calling the background script (for example, when there is only one page in history), I do think we should move the history navigation functions to the background utils.
As part of this, we should remove the (now unused) focus retention strategy that stored the focus index in local storage.