Bookmarklet to inject opfs loader/saver into any online tiddlywiki

I have written a javascript bookmarklet to inject an OPFS loader/saver into the tiddlywiki on your browsers current page.

You can install it by visiting this share site url containing the bookmarklet.

After clicking the bookmarklet, any changes will be automatically saved by writing the entire single-file wiki into the browser’s internal OPFS storage. After refreshing the page, the original wiki will be displayed. Click the bookmarklet again and the changed file in the browser’s internal storage will be loaded. Changes will continue to be saved.

I had the idea to do this after reading @TW_Tones post:

It is kind of clumsy to work with, but it might be useful for some things. I don’t recommend using it to store anything important.

You can export the OPFS wiki by finding the download button in the wiki (i.e. use advanced search to find the $:/core/ui/DownloadFullWiki tiddler).

Very interesting approach.

That’s pretty cool. There are other projects that depend completely on this kind of storage.

What is the capacity of OPFS?

One thing, is that the title in the tab bar doesn’t reflect the OPFS version of the TW file.

When it’s in the OPFS save mode, even typing in a new title isn’t reflected in the tab listing. The OPFS saves the title in the control panel, but the title in the tabs bar stays the same.

This is on Firefox.

Yes, for instance when you choose “Internal File Access” at Tiddlystow put saver, OPFS is being used.

Here are the details on that. Looks like at least 10GB:

Yes, I also noticed if you try to get a permalink, the link copied to the clipboard is not very good. (starts with about:srcdoc instead of the actual url) and it is not updated in the url bar. I think the reason is because the “parent” wiki is being hidden and the opfs file is is being loaded into an iframe:

      [...document.body.children].forEach(el => el.style.display = 'none');

      const iframe = document.createElement('iframe');
      Object.assign(iframe.style, {
        position: 'fixed',
        top: '0', left: '0', right: '0', bottom: '0',
        width: '100%', height: '100%',
        border: 'none',
        zIndex: '2147483646',
      });

      iframe.srcdoc = existingHtml;
      document.body.appendChild(iframe);

      console.log('[OPFS saver] reloaded wiki from OPFS into iframe');

compare that to tiddlystow v1 code where I replace the “parent” document with the new html:

I didn’t try that approach with this because as far as I know, replacing the document does nothing about the javascript already loaded into the page. I was worried about there being strange interactions between javascript in the original wiki vs. the one loaded from opfs.

I was thinking of non-TiddlyWiki projects.

Looks like it stopped being supported. It’s almost as old as TW5!

I think Silver Bullet may also use a similar system, but I haven’t kept up with it.

@btheado Brian, thanks for running with this. I have tried the tool with mixed results.

I will test it further but my first observation is;

Now for the future.
As you note it is required on returning to a read only wiki to once again install the bookmarklet, one needs to know this is so or we may forget we have saved changes.

It seems to me we could add to the core a small script to test for and execute the equivalent of the bookmarklet if the storage exists. Perhaps with a “restore saved content” prompt. Because this “boot loader” would be part of the core, it would also be part of future read only wikis.

  • It would still require the first bookmarklet execution to start the save process
  • For security we could add a url based key that is checked against the current address/url so this could not be inserted surreptitiously.

Love your work :nerd_face:

This is another issue resulting from the implementation loading the wiki into an iframe. Your bookmarklets have javascript referencing $tw and the bookmarklet’s javascript will run in the top level browser window. If you have already saved and loaded from opfs storage, then the original “outer” wiki is hidden and only the frame is visible. However, your bookmarklet is operating on the outer wiki and doesn’t touch the one running in the iframe.

Clearly the use of the iframe causes multiple issues.

Thanks for sharing this approach. I have researched OPFS and ChatGPT says it can build a HTA like solution, so I am looking a little further.

It seems confused between single file and node implementations.

I was able to get this to work with Vivaldi for Android. I had to run the code through a minifier first. This might be a good approach for people to continue using TiddlyWiki if Google blocks it’s distribution in the coming year.

How do we purge the OPFS for a site, should the need arise?

Thanks!

Nice. It supports bookmarklets on android?

I guess it has a small size limit for bookmarklets? As you probably saw, my version of the bookmarklet only url encodes and does not make any minification attempts.

Google might block distribution of Tiddlywiki? Or is “it’s” referring to something else in your statement?

I recommend frequently downloading backups of your wiki. The bookmarklet is a little raw and only reports to the console if the request for “persistent” storage is denied. Firefox makes it more visible by explicitly asking the user for permission. I think chrome automatically denies the permission unless you have the site bookmarked or added to your home screen (or maybe if you visit often enough).

I haven’t seen a native way through developer tools to do so. One way is to use this browser extension: GitHub - hasanbayatme/opfs-explorer: Inspect, manage, and edit files in the Origin Private File System directly from Chrome DevTools. · GitHub. It adds an “OPFS explorer” tab to developer tools.

Or you can ask an ai to generate javascript code to do it and make a bookmarklet from the result.

It seems to work. But you invoke it by typing a keyword in the url bar, and then selecting the bookmarklet to run.

That’s what I would guess. Don’t know what the precise limit is.

Sorry, I rewrote the statement like 3 times, and managed to omit the topic. Starting in September, Google is going to prevent the deployment of unregistered 3rd party apps on Android. This would presumably include Tiddloid, FDroid, and anything you might want to load through FDroid (Including Tiddloid). To get around this, someone would have to register Tiddloid (or a similar app) with the Playstore.