[IDEA] Use browser navigation with History API

[yaisog]

Would it make sense to anyone else but me to use the Browser History API to "hijack" the browser's back and forward buttons to navigate to previously visited tiddlers? Especially together with mouse gestures, this could save a lot of time.

Basically, it could work like this, I think: A listener widget inside the main NavigatorWidget attaches an EventListener for popstate to the window that dispatches tm-navigate messages that bubble upwards whenever back or forward are clicked. That navigates to the tiddler that is saved in the browser history stack.

To get tiddlers into the browser history, an action widget could put it there. This widget would need to be called whenever a tiddler is to be added, by a button action or by intercepting tm-navigate messages in the PageTemplate (there have been discussions about how to do this here and on TalkTW) and writing into the browser history on navigation. Using pushState on the history object, we can save the navigation target tiddler there. This could be done without changing the URL (sort of the opposite of what PermaLink and PermaView do).

It would also be nice if the back button were not able to exit TW, as otherwise one careless click would cause users to have to reload the wiki. I'm sure there are ways to do that. Hopefully.

[pmario]

You can use the ControloPanel -> Settings -> Navigation Address Bar settings.

• The default for new wikis if off
• You need to switch it on
• Save and reload ... at least for me it works that way.

[yaisog]

Hi @pmario, this is pretty cool. How did I not know about this?
But back / forward only work if Navigation History is also enabled:

Unfortunately, activating Navigation History but selecting Do not update the address bar does not work. I had hoped that this would enable back / forward without changing the URL that is shown. But it deactivates the history feature.

Also, there is no protection against pressing "back" once too often. Especially in auto-save or node.js wikis you won't even be asked if you want to leave.

[yaisog]

Also, the current system is hash-based, so it can't work without changing the displayed URL. My proposition uses the History API which doesn't care about whether the URL changes or not.

[yaisog]

Also, there is no protection against pressing "back" once too often. Especially in auto-save or node.js wikis you won't even be asked if you want to leave.

After some reading it seems that targeting only an exit via the Back button is not possible. A beforeunload warning would appear just before any way to leave the wiki is triggered (closing the tab, opening a different URL). This is maybe not what everyone wants and is maybe better implemented as a plugin.

[yaisog]

I made a draft PR to explore how browser history navigation could work without using the location hash, see #9608.

[ericshulman]

targeting only an exit via the Back button is not possible

Give this a try:
https://tiddlytools.com/#TiddlyTools%2FPanels%2FBrowser%2FNoExit.js

I wrote this specifically for use with my TiddlyTools/Panels/Browser "minibrowser", so that "one careless click" while navigating pages within an embedded IFRAME won't accidentally exit the parent URL.

What it does:
At startup, push the location.href to the history state stack and call history.back(); history.forward();. This ensures that the current URL is "primed" into the history. It then sets up a window.onpopstate handler to catch the back button so that attempts to exit the current URL trigger a history.forward() to effectively keep from exiting.

Note that this JS code is a startup module, but the module-type field has been deliberately omitted from the tiddler so that the code disabled by default. After copying the above tiddler to your TiddlyWiki, you will need to add a module-type field with a value of startup and then save-and-reload for it to take effect.

-e

[yaisog]

Hi @ericshulman, that's a pretty interesting approach. But I need both the back and forward navigation to work. As far as I can tell from a quick glance, your solution simply undoes every Back click by immediately clicking Forward?

I did find a solution that I'm pretty happy with that I haven't pushed yet, because it's unfinished. Upon startup a push a special warning tiddler to the history stack. If a user clicks Back too often, he/she will eventually arrive at the warning tiddler which says something like "If you click Back one more time, you'll leave the wiki." This worked pretty good for me in first tests.

[yaisog]

I updated PR #9608 with the history backstop feature.