[twdev] Re: Weird behavior of File Backups with TWc

[Yakov]

Hi Mario,

thanks for the Unix path fix tip, I'll add it to the next update of Timimi 
too.

I'll have a closer look at other info too; a quick note for now: could you 
fix the url calculation to support non-ASCII paths like I've introduced in 
Timimi 
?
 
(note encodeURIComponent instead of escape there, in my tests limited to 
Windows that fixed loading from paths containing non-ASCII symbols and 
didn't broke anything) Yeah, those bugs and fixes are scattered among 
various solutions.. that reminds me again that we need docs 
/common 
codebase for this, I'll definitely return to that at some point.

Best regards,
Yakov.

четверг, 29 августа 2019 г., 10:47:06 UTC+3 пользователь PMario написал:
>
> On Wednesday, August 28, 2019 at 10:29:42 PM UTC+2, Yakov wrote:
> ...
>
>> As for your initial problem, try to disable 
>> security.fileuri.strict_origin_policy option in your FF's about:config. 
>>
>
> Not everyone is comfortable disabling "security" related settings, since 
> there is a reason for them, as BJ pointed out: 
> https://www.mozilla.org/en-US/security/advisories/mfsa2019-21/#CVE-2019-11730
>  
>
>> I suspect that the culprit is recreateOriginal 
>>  
>> which doesn't take into account some aspects of saver plugins;
>>
>
> With the fix, that I implemented this workaround is not called anymore, 
> since the intended function 
> 
>  
> is called and succeeds. 
>
> And yes. It seems recreateOriginal causes a backwards compatibility 
> problem, with every TiddlyFox compatible saver addOn. ... The original 
> TiddlyFox addOn did create a DOM element named: tiddlyfox-message-box
>
> At the init-phase of the AddOn startup, we check for the existence of this 
> element and add a marker. So other AddOns, that know about it, can print a 
> message, that only 1 saver addOn can be active at the same time. If an 
> other SW is detected, the add-on disables itself. ... see my addOn code 
> .
>  
> BJ has a similar function.
>
> *This DOM element should not be saved to the file*. ... It seems if 
> "recreateOriginal" is called, it is saved and breaks the file, so it can 
> only be fixed with a text editor, removing the element. 
>
> The problem I had to fix, was a difference between unix file paths and 
> windows file paths. see line 51 and 54 
> .
>  
> The "old" code was windows compatible, but caused a problem for unix 
> systems with the security.fileuri  setting activated. ... So there 
> may be a similar fix for timimi. 
>
>
> current Timimi implementation has a similar issue 
>> , which I haven't 
>> reproduced yet but I'll check my guess too.
>>
>
> I'll have a closer look, maybe I can help there. The "old" code was 
> windows compatible, but caused a problem for unix systems with the 
> security.fileuri  setting activated. ... So there may be a similar 
> fix for timimi. 
>
>
> have fun!
> mario
>

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/2fc05a37-e1ea-403c-b34a-d6e09652779a%40googlegroups.com.

Re: [twdev] Re: TWC: Is it a good idea to save asynchronously?

[BJ]

with the latest code both twc and tw5 are supported on ff and chrome, but
only versions of twc that support the html5 download mechanism (I think a
html5 twc plugin could be written for olderversion).

cheers

BJ
On Wed, 28 Aug 2019 at 22:37, Yakov  wrote:

> Hi BJ,
>
> thanks for both the update/release and the TiddlyTools link. I'll update
> the latter on classic.tiddlywiki.com; I can't predict how soon I'll try
> SaveTiddlers by itself, but the codebase is quite valuable since it covers
> FF *and* Chrome. Did I get the readme.md right that TW5 is saved in both
> Chrome and FireFox while for TWC only FF is supported?
>
> Best regards,
> Yakov.
>
> вторник, 6 августа 2019 г., 13:09:47 UTC+3 пользователь BJ написал:
>>
>> I have made a new version of savetiddlers for classic tw to work with the
>> lastest firefox - I would appreciate it if you (or others) could try it.
>>
>> thanks
>>
>> bj
>>
>> https://github.com/buggyj/savetiddlers/releases/tag/0.9
>>
>> On Tuesday, July 23, 2019 at 9:15:44 AM UTC+2, Yakov wrote:
>>>
>>> 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 a topic in the
> Google Groups "TiddlyWikiDev" group.
> To unsubscribe 

[twdev] Re: Weird behavior of File Backups with TWc

[PMario]

On Wednesday, August 28, 2019 at 10:29:42 PM UTC+2, Yakov wrote:
...

> As for your initial problem, try to disable 
> security.fileuri.strict_origin_policy option in your FF's about:config. 
>

Not everyone is comfortable disabling "security" related settings, since 
there is a reason for them, as BJ pointed out: 
https://www.mozilla.org/en-US/security/advisories/mfsa2019-21/#CVE-2019-11730
 

> I suspect that the culprit is recreateOriginal 
>  
> which doesn't take into account some aspects of saver plugins;
>

With the fix, that I implemented this workaround is not called anymore, 
since the intended function 

 
is called and succeeds. 

And yes. It seems recreateOriginal causes a backwards compatibility 
problem, with every TiddlyFox compatible saver addOn. ... The original 
TiddlyFox addOn did create a DOM element named: tiddlyfox-message-box

At the init-phase of the AddOn startup, we check for the existence of this 
element and add a marker. So other AddOns, that know about it, can print a 
message, that only 1 saver addOn can be active at the same time. If an 
other SW is detected, the add-on disables itself. ... see my addOn code 
.
 
BJ has a similar function.

*This DOM element should not be saved to the file*. ... It seems if 
"recreateOriginal" is called, it is saved and breaks the file, so it can 
only be fixed with a text editor, removing the element. 

The problem I had to fix, was a difference between unix file paths and 
windows file paths. see line 51 and 54 
.
 
The "old" code was windows compatible, but caused a problem for unix 
systems with the security.fileuri  setting activated. ... So there may 
be a similar fix for timimi. 


current Timimi implementation has a similar issue 
> , which I haven't 
> reproduced yet but I'll check my guess too.
>

I'll have a closer look, maybe I can help there. The "old" code was windows 
compatible, but caused a problem for unix systems with the security.fileuri 
 setting activated. ... So there may be a similar fix for timimi. 


have fun!
mario

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/cfdba26c-361a-4d97-9ee4-c80ba1d173ba%40googlegroups.com.

Re: [twdev] Re: How to use Node modules in browser?

[bimlas]

 

> Yes, it should be documented there.
>

Opened https://github.com/Jermolene/TiddlyWiki5/pull/4213 

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/49a9e3e1-d2c8-4a4e-bd4d-3076c6bcb776%40googlegroups.com.

Re: [twdev] Re: How to use Node modules in browser?

[bimlas]

Opened https://github.com/Jermolene/TiddlyWiki5/pull/4211 
and https://github.com/Jermolene/TiddlyWiki5/pull/4212

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/3d4f66cb-bd00-4e8d-ba63-28f599086729%40googlegroups.com.

Re: [twdev] Re: How to use Node modules in browser?

[bimlas]

Jeremy

I found why my files didn't load: the code above 
(https://groups.google.com/d/msg/tiddlywikidev/wKqzwaMfBJw/YwJVbBjGBAAJ) 
works, but only if I am not using a system tiddler, as they are not loaded 
by Syncadapter.

The description of Syncadaptor is ambiguous 
(https://tiddlywiki.com/dev/#Syncadaptor): "provides functionality ... to 
load, save and delete single tiddlers ... honours a special system tiddler 
$:/config/SyncFilter containing a filter string. Tiddlers matching this 
filter string are not synced with a syncadapter." The reality is that it 
uses the *$:/config/SyncFilter* filter when saving *from* *browser to 
server*, but ignores all system tiddlers when syncing *from* *server to 
browser* (by using */recipes/default/tiddlers.json*).

[image: tiddly-sync.png]

*(Not a real UML, but I hope it helps understanding.)*

As far as I can track back in Git history, filtering system tiddlers is 
intentional (and logical), but not mentioned in the documentation.

-- 
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 tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/570cad60-2bd8-473a-aa9e-71fcd0ceba2d%40googlegroups.com.