NoScript seems to break TiddlyWiki editing

This issue has been tracked since 2022-09-27.

I'm trying to better understand a problem I see when I view a plain old TiddlyWiki ( 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 (, 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/[]/Downloads/PersonalWiki/wiki.html DocumentFreezer.js:101:15
Suppressing readystatechange on  
HTMLDocument file:///C:/Users/[]/Downloads/PersonalWiki/wiki.html
Unfreezing file:///C:/Users/[]/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?

More Details About Repo
Owner Name hackademix
Repo Name noscript
Full Name hackademix/noscript
Language JavaScript
Created Date 2018-06-30
Updated Date 2022-12-03
Star Count 573
Watcher Count 21
Fork Count 79
Issue Count 151


Issue Title Created Date Updated Date