Use browser history when updateHistory="yes" and updateAddressBar="no"

[yaisog]

Until now navigation via the Back and Forward buttons is only enabled when $:/config/Navigation/UpdateAddressBar is set to permalink or permaview if $:/config/Navigation/UpdateHistory is also set to yes. This PR would also enable the use of these buttons when UpdateAddressBar is no. Instead of changing the locationHash, the navigated tiddler is added to the browser history state object. A popstate handler is added to the window object that evaluates the state object and if it exists then navigates to the tiddler described therein.

The implementation includes a backstop feature that defines a boundary tiddler at the beginning of the browser history stack. The tiddler that is shown as a backstop can also be configured via $:/config/Navigation/HistoryBackstopTiddler. It prevents users from navigating beyond their TiddlyWiki session when using the browser's back button. Before leaving the wiki, they'll reach the configured backstop tiddler showing a corresponding warning.

Resolves #9604

PS: In the preview, $:/config/Navigation/UpdateHistory is set to yes by default to make testing the feature easier.

[netlify]

✅ Deploy Preview for tiddlywiki-previews ready!

Name	Link
🔨 Latest commit	0f41173
🔍 Latest deploy log	https://app.netlify.com/projects/tiddlywiki-previews/deploys/697b88f1650202000710cbb6
😎 Deploy Preview	https://deploy-preview-9608--tiddlywiki-previews.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[github-actions]

Confirmed: yaisog has already signed the Contributor License Agreement (see contributing.md)

[github-actions]

📊 Build Size Comparison: empty.html

Branch	Size
Base (master)	2450.9 KB
PR	2456.8 KB

Diff: ⬆️ Increase: +5.9 KB

---

✅ Change Note Status

All change notes are properly formatted and validated!

📝 $:/changenotes/5.4.0/#9608

Type: enhancement | Category: internal
Release: 5.4.0

Enable browser navigation without changing location hash

🔗 #9608

👥 Contributors: yaisog

---

📖 Change Note Guidelines

Change notes help track and communicate changes effectively. See the full documentation for details.

[pmario]

I assume, these 2 settings are only set for testing. right?

[yaisog]

That's right. Otherwise, you'd have to set this manually each time you load the wiki.

[pmario]

We will need new setting options in the ControlPanel - Settings tab

[yaisog]

Actually, I think we don't. This PR just combines the UpdateAddressBar option "Do not update the address bar" with the UpdateHistory option "Update history". This combination had no effect until this PR, but describes accurately what is happening here.

[yaisog]

I added a history backstop, which is a tiddler that is shown before another click on "Back" would leave the wiki. This is more specific than a general warning when leaving the wiki by any means.
Something similar might also be useful for the permalink and permaview modes, with which I don't have much experience, though.

[ericshulman]

Could this whole mechanism be implemented as a plugin? At the very least, that would allow it to be available much sooner, and would also help to demonstrate its general stability and gauge its appeal/usefulness to the TW community at large.

I also wonder if the "backstop" feature could be implemented as a separate (and much simpler) "always ask before exiting" feature, independent of the "use browser history to navigate" functionality.

Ideally, I'd also like the "HistoryBackstopTiddler" to be able to optionally just invoke action widgets instead of being displayed in the StoryRiver. This could then be used somewhat like the "ConfirmBeforeExit" plugin I wrote for TWClassic (which also closed active tiddler editors and then prompted to save before continuing to exit.

[yaisog]

Hi @ericshulman, the startup part (preparing the history and attaching the eventListener) could easily be externalized into a plugin, but updating the history on each navigation event alters the updateLocationHash() method of startup/story.js. One could put this in a plugin, but then that plugin must be updated (by the maintainer and the user) to benefit from core updates. I could, probably, instead of attaching to the existing change event listener, create an extra listener that does the history updating. This would be plugin-compatible.

I like your action widget idea. I think it would make sense to use a tag-based approach and execute all actions in tiddlers with something like $:/tags/HistoryBackstopActions and only show the backstop tiddler if no actions are defined.
I'd have to check what is possible if you wanted to have a general beforeunload mechanism that would call actions. I'm not sure if more than a confirmation message is possible here.

I also wonder if the "backstop" feature could be implemented as a separate (and much simpler) "always ask before exiting" feature [...]

When I took this functionality out of this PR, I actually put it into a plugin:
$__plugins_yaisog_warn-on-unload.json

[ericshulman]

$:/tags/HistoryBackstopActions

I feel that "HistoryBackstopActions" is too technical. How about calling it $:/tags/ExitActions?

This could be used so that whenever you try to leave the TiddlyWiki, it could reset various $:/state tiddlers to their initial defaults, then check for unsaved changes and prompt (using a tm-modal) for "Save before exiting?" with buttons for "cancel", "save", and "don't save". Choosing "save" would then trigger a tm-save-wiki.

As you've noted, 'onbeforeunload' is specifically limited to returning ONLY a confirmation message, so the above handling would somehow have to be triggered separately, if that is possible.

[yaisog]

$:/tags/ExitActions might be too general, especially if it applies to exit via history only. Maybe $:/tags/HistoryEndActions?

I've checked again and I don't think there is a beforeunload-like mechanism that will let us trigger action widgets when the wiki tab or window is closed or the user navigates away. The current confirmation dialog is probably as sophisticated as it gets. (Which might be a good thing, thinking back to the early web when malicious websites could trap users in very frustrating ways...)

Regarding the history backstop, when this is shown, the user likely doesn't want to navigate away from the wiki. Thus, resetting state tiddlers and saving might be premature. An alternative to the backstop tiddler that could be invoked would be a notification or a warning modal (which could have an exit option via history.back(), which cannot be triggered via action widgets, though).

The usefulness of the exit actions is unfortunately pretty much limited to browser back / forward navigation and preventing accidental wiki exits...

[yaisog]

Hi @ericshulman, concerning the plugin: I made a "prerelease plugin" that takes the exact code of this PR and makes it into a plugin. This way, the chance for a serious conflict if someone with the plugin upgrades to 5.4.0 would be minimized, because the plugin wouldn't change the core code.
Seeing that this PR seems to have been pushed back to 5.5.0, I'll probably make a "real" plugin that only contains the code needed for the new functionality, but leaves story.js alone. This is going to have to wait another day or so, though...

[yaisog]

Hi @ericshulman, as you might have seen on Talk TW, I made a true plugin with this functionality that should integrate in any wiki without needing to replace story.js. This will probably make it more difficult to roll out the same functionality as a core feature at some point in the future, but it is available much sooner.
If you have more ideas how to improve it, let me know here or on Talk.