Firefox compatibility problems?

Compiler: tweego v2.1.1+81d1d71 (2020-02-25T07:09:26Z) [windows/amd64]
Story Format: SugarCube v2.34.1

Are there any known compatibility problems with Firefox v 85.0.1?

Immediately after a story’s opening is rendered, I get a story error popup which says
Error: can’t redefine non-cofigurable property “_real_stringify”.

This problem is encountered when Firefox v85.0.1 is not already open and I click on (select) an HTML file generated by tweego. This problem is also encountered when Firefox is not already open and I “drag and drop” the HTML file onto Firefox’s desktop icon.

This problem is NOT encountered if Firefox is already running (e.g. while posting here), in which case a new tab in the current browser window is opened. It also is not encountered if I “drag and drop” the HTML file onto the desktop icons of other browsers, including Firefox ESR, Waterfox and Vivaldi.

I’ve cleared Firefox’s cache and cookies, but the problem stll exists.

This happens for a minimal twee file which contains only the following text:

:: Start
Go to the [[End]].

:: StoryInit

:: StoryData
        "ifid": "C31A5464-60FC-4937-A550-C7D75F7692AF"

:: StoryTitle

:: Story Stylesheet [stylesheet]

:: Story JavaScript [script]

:: End
!! This is the End

Edited to add:
Here’s a zip containing the HTML file: (140.4 KB)

Also, I’m running under Windows 10 Pro, release 20H2, with patches as of the January update.

I ran into the same issue, but your case looks even more clear cut than mine.

I’d recommend posting to that link and hopefully TheMadExile will reopen that issue and fix it for you.

Not to my knowledge, no. Despite being available for about 2½ weeks now—for download, on the CDN, and bundled with Twine 2—there have been no reports of major issues, aside from a nested SVG bug that’s been fixed in the repo.


That specific error has come up once recently. The cause then, as likely now, is that something is causing the page to be re-parsed, specifically SugarCube’s main script. The main script being re-executed is causing various immutable identifiers to be redefined, which fails because they’re immutable.


I cannot reproduce the issue using that file, with the same version of Firefox (v85.0.1 64-bit) or any other.

I’m going to assume you’re using add-ons. If so, please see if disabling them and retrying that file resolves the issue. If not, go ahead and leave a comment with as much detail as you can in the existing issue—also linked above by HiEv.

The problem is seen when the Firefox Addon NoScript (v11.2, dated January 27th; ) is enabled, even though scripts which originate from the local computer’s disk are permitted. I guess it’s not surprising that NoScript would have interactions with SugarCube. :frowning:

Unfortunately, i’m very reluctant to disable NoScript in my default browser.

Edited to add:

Since this problem is seen only if Firefox is not already running, so that selecting the story script causes Firefox to start from scratch, fixing it isn’t urgent, although it’d be nice if the error popup were more informative.

While this specific instance is something I could probably work around, I have no real desire to. At the moment, I have no clear idea how many other instances of similar code would run into the same problem, nor how easy they’d be to work around.

NoScript should not be causing any page script to execute more than once—that’ll cause issues for more than just SugarCube. This almost has to have been either a recent change in NoScript or its configuration, as code exactly like what’s exploding for you now has been part of SugarCube for going on six years now. This is not a new thing on SugarCube’s part.


I can’t reasonably change the relayed error message as it’s from the environment, due to the access violation.

To be clear. Yes, I could catch the specific error being thrown here and attempt to massage the error into something nicer. The problem with that is similar code exists elsewhere and minor changes to the build process could reorder the code thereby placing one of the other, unguarded, instances above the one you’re bumping into now. Thus causing the issue again.

Ultimately, I really do not want to start playing code whack-a-mole simply to work around or polish up errors that come from the behavior of a browser add-on.

I’ve submitted a problem report to the NoScript forum. It can be seen at

The bug in NoScript has been fixed in Version 11.2.1rc1, which is currently available at
“x Prevent double script on trusted file:// pages in some edge cases”
I dunno when it’ll be released.