Hi BJ, when saving the function recreateOriginal() is used to create the new twc > image >
yeah, yesterday I figured too that its the source of the problem. I use a plugin which overwrites loadOriginal to remove using recreateOriginal because TiddlyFox wrongly always reports successful saving and I have some TWs on an ejectable USB storage, so I need to be sure that if saving failed TW reports fail (TW may be still opened but the storage may be ejected). That's why I overlooked the issue. With chrome and now with firefox (since version 68) loading files from > 'file:/' is blocked due to security concerns > That's not quite true, setting security.fileuri.strict_origin_policy in FF still makes it possible to load files via xhr through file: schema (I haven't tested much, but launching Chrome with the --allow-file-access-from-files param should do so as well). It would be better to remove the message box from the new image. At present > savetiddlers will not work with a twc that already has a message box div - > I will work around this and produce a new release. > Could you provide some more details on why it doesn't work now? Because I'm considering even adding the message box to the core so that development of future savers that use the event-driven saving is easier. *Pengju Yan wrote* > > A really serious problem in savetiddlers is the mechanism of avoiding > saving the same file while a previous saving is not finished. Check the > dict "debouncing" in "contentscript.js". > > In several cases, the dict "debouncing" was not cleared as expected then > all my subsequent work was lost without my awareness (I enabled autosave > and savebackups). I've been suffering from this time by time. > Oh gosh, do you mean you had 2 subsequent saves with a little time gap between them? (could you describe your scenario so that I'm more aware of this potential problem? MainTiddlySaver hasn't debouncing implemented yet, but I never experienced this problem with content, only with options storage) If there's such problem, we should describe it in detail and refer to this in future development; I wasn't expecting anything like this in an extension saver (or may be the source of the problem is a bit different from what you describe?) We really need a reproducible scenario. Also, the dirty flags of successive savings should be managed in a stack > and cleaned in a proper way (delete certain dirty flags upon receiving > certain "save-successful" messages). > Yeah, I second this proposal (thinking about it for some time already), but this is a second level of IO improving which I'd address when a) I finish making TWC saving async and b) some documentation about IO/developing savers and editing (collaborating) workflow/infrastructure is established – because this is a more complicated idea and is less trivial to implement, especially when there's no docs describing it. Best regards, Yakov. вторник, 23 июля 2019 г., 4:43:17 UTC+3 пользователь Pengju Yan написал: > > > On Saturday, July 20, 2019 at 11:14:55 PM UTC+8, Pengju Yan wrote: >> >> Continue the title with "Or we need to modify TWC core substantially?" >> >> To enable asynchronous loading and saving, I think we need to modify TWC >> core so that only if a "save-successful" message is received then the dirty >> flag could be set to false. >> >> > Also, the dirty flags of successive savings should be managed in a stack > and cleaned in a proper way (delete certain dirty flags upon receiving > certain "save-successful" messages). > > -- You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/3bf34607-a579-4dff-b6e8-fef8e3905859%40googlegroups.com.
