I'm trying to better understand a problem I see when I view a plain old TiddlyWiki (https://tiddlywiki.com/) local file (e.g. file:///C:/Users/[me]/Downloads/.../wiki.html) and create a new tiddler, where the preview panel appears to be disabled and, upon entering text and 'confirming changes', all the text entered in the main tiddler contents text box appears to get lost, leaving an emtpy new tiddler.
I'm using Firefox(Win, 106.0b4), which also has the NoScript (v11.4.11) addon enabled, but with the TW file marked as trusted in NoScript's settings for the page.
After a little hunting around, I found this old issue/discussion -
that has a very similar description and points the finger at a problem in NoScript (https://forums.informaction.com/viewtopic.php?f=7&t=26089&sid=f24592d36af1345e52ed255030f05a99&start=30), but which was supposedly fixed in newer NoScript version.
In trying to test whether NoScript is at fault, I entirely disabled the plugin, opened my local wiki file, and was able to add, edit, and preview a new tiddler just fine. Then, when re-enabling noscript and repeating the whole process, the problem returns.
I thought I might try to get a little bit more of an understanding of what's going on, so, as mentioned in the above tiddlywiki issue thread, I've been looking at the firefox developer console messages panel, comparing the output for trying to add/edit a new tiddler between when NoScript is disabled and when it's enabled. Both produce identical dev console output, except only the 'NoScript plugin enabled' case has the following additional output, right at the end -
Freezing file:///C:/Users/[...me...]/Downloads/PersonalWiki/wiki.html DocumentFreezer.js:101:15 Suppressing readystatechange on HTMLDocument file:///C:/Users/[...me...]/Downloads/PersonalWiki/wiki.html DocumentFreezer.js:38:13 Unfreezing file:///C:/Users/[...me...]/Downloads/PersonalWiki/wiki.html DocumentFreezer.js:117:15 Opened null syncFetchPolicy.js:132:23 This page is in Quirks Mode. Page layout may be impacted. For Standards Mode use “<!DOCTYPE html>”. wiki.html
Does someone who better understands this log output know whether NoScript is at fault, given that I've configured my wiki file url to be fully trusted in the NoScript plugin? Has a previous fix somehow been lost, reintroducing a bug, or is this pointing at a whole new issue with NoScript ... and can it be fixed?
|Issue Title||Created Date||Updated Date|