Unsaved Changes Warning With MultiUser Plugin

[Kevin Kleinfelter]

When using the wonderful MultiUser Plugin, after adding new tiddlers and letting them complete the auto-save, I get the unsaved-edits warning when navigating away from the page.  This happens whether I use the single-executable or the manually-installed plugin.  It doesn't happen with a generic TW5.

Jeremy explained a method to suppress the message entirely.  I'm reluctant to do that because I do want to be notified if auto-save somehow failed, and I need to manually save changes.

Is there a way to get the unsaved-edits message to show up with the MultiUser plugin, only when there are *unsaved* changes?

Thanks!

======

Relevant browser messages:

Safari: Are you sure you want to leave this page?

Firefox: This page is asking you to confirm that you want to leave - data you have entered may not be saved.

Chrome: Do You Want to Leave This Site? Changes you made may not be saved.

[TonyM]

Kevin,

I get this too, but now I rely on the Save Icon to no longer be red, to confirm save.

But it is a little disconcerting.

Regards

Tony 

[Jed Carty]

That message has no meaningful interaction between that message and what needs to be saved by the plugin so turning it off isn't going to cause problems.

[Kevin Kleinfelter]

Hmmm... Ironically, it appears that sometimes changes aren't fully saved for me.

I'm running with node.js inside a Docker container.  I exposed ports 8080 and 8081.  When I save a title-only tiddler (i.e. click the new-tiddler button and immediately save the new tiddler without entering a body):

• The logger says the file was saved.
• The file really is saved in the file system.
• The tiddler does not show up in the Recents list.
• After reloading the page, the tiddler does not exist.

This behavior only happens when running in a container with the plugin.  It looks like it either uses an additional port (maybe briefly) or there's something not passing through the exposed ports.  I confirmed that there is no issue when running the same version of TW in the same container, without the plugin.

I can go to the wiki data folder in file system and execute "touch *" and all missing tiddlers immediately show up in the browser.

Any ideas for debugging?

[Jed Carty]

Check the 'all' tab, the tiddlers may be created and not listed under 'recent'. There is probably a bug left over from an old way of saving tiddlers I used where the creation fields aren't added to a tiddler if all fields except title are empty when it is made. The solution is for me to use the normal render command to save the tiddlers but I haven't gotten around to it because from what I can tell this is the only problem caused by it.

[Kevin Kleinfelter]

Ah!  You are right.  It *is* just the Recent tab that's missing them.

It is curious that it occurs only when running in a Docker container.  If you're not familiar with Docker and 'containers':

• I'm running the TW node server in a lightweight VM.
• The VM's network is isolated from the host, where I'm running the browser, except for ports I designate as pass-through.
• The VM's file system is isolated from the host's file system, except where I permit otherwise.

If nothing else, just pretend I have a firewall which permits only traffic between the server and the browser on the ports I specify, and never on IP 127.0.0.1.

I'm running TW with the following command line:

• /usr/local/bin/node ./tiddlywiki.js editions/MultiUserWiki  --wsserver 8080 ${USERNAME:-user} ${PASSWORD:-'wiki'} 0.0.0.0
  

It is necessary to bind to IP 0.0.0.0 (all IP) because binding to 127.0.0.1 in the VM is available only within the VM, so I need it to bind to the vNIC that connects to the host network.

When I run a browser from another machine, I get similar (but not identical) behavior, when Docker is not involved.  Adding a tiddler from another machine's browser gets no reference added to Recents, but it does show up after a page refresh.

If I had to guess, I'd guess there is something in the plugin which assumes 127.0.0.1 can be used to connect.

Thanks for your help and thanks for the plugin.  Really nice piece of work.

[Jed Carty]

The wsserver command should ignore the command line arguments. The parameters are taken from the settings.json file in the settings folder. It sounds like the web socket connection isn't making it outside the container. It sounds like the websocket connection is only going one way, I am not sure if the docker container could cause something like that.

If you can see the terminal output it should list the ports being used so you can make sure the ports are what you are expecting.

One possible cause may be that the way that the server determines the correct ip address to use for the websocket connection may not work from inside the container.