Page 3 of 3

Re: Noscript puts FF in a reload loop

Posted: Thu Aug 20, 2020 2:34 pm
by TiddlywikiUser
This issue seems related to one I've been having with local files.

Downloading an empty copy of Tiddlywiki (blue "Download Empty" button at https://tiddlywiki.com/static/GettingStarted.html) and running it locally (with javascript enabled) in Firefox 79, then editing the GettingStarted entry by clicking the pencil icon causes the entire page to be reloaded within the editing frame. Clicking any editing/pencil icon on the Tiddlywiki main site with Javascript enabled displays expected behaviour. It only occurs when 11.0.38 and 11.0.39rc6 are running, all prior versions seem to behave normally.

Re: Noscript puts FF in a reload loop

Posted: Fri Aug 21, 2020 6:25 am
by skriptimaahinen
staticNS.js:104

Code: Select all

documentCSP.apply(new Set()); // block everything to prevent leaks from page's event handlers
Is the above actually necessary? The root attributes are already removed in the beginning of this file. Sure, they are put back in the setup(), but they should be subject for the CSP now.

.39rc8 does fix the beforeunload problem, but the problem with alert (blocked DOM) still persists.

Re: Noscript puts FF in a reload loop

Posted: Fri Aug 21, 2020 7:48 pm
by Giorgio Maone
skriptimaahinen wrote:
Fri Aug 21, 2020 6:25 am
.39rc8 does fix the beforeunload problem, but the problem with alert (blocked DOM) still persists.
Please check latest development build:
v 11.0.40rc1
============================================================
x Handle edge case in file:// pages: policy change and
reload before DOMContentLoaded

Re: Noscript puts FF in a reload loop

Posted: Fri Aug 21, 2020 7:50 pm
by Giorgio Maone
TiddlywikiUser wrote:
Thu Aug 20, 2020 2:34 pm
This issue seems related to one I've been having with local files.

Downloading an empty copy of Tiddlywiki (blue "Download Empty" button at https://tiddlywiki.com/static/GettingStarted.html) and running it locally (with javascript enabled) in Firefox 79, then editing the GettingStarted entry by clicking the pencil icon causes the entire page to be reloaded within the editing frame. Clicking any editing/pencil icon on the Tiddlywiki main site with Javascript enabled displays expected behaviour. It only occurs when 11.0.38 and 11.0.39rc6 are running, all prior versions seem to behave normally.
This seems to be fixed to me now (tested on 39rc8 and 40rc1). Please confirm, thanks.

Re: Noscript puts FF in a reload loop

Posted: Sat Aug 22, 2020 6:49 pm
by FranL
v 11.0.39rc6
============================================================
x Fix reload loops on broken file: HTML documents (thanks
bernie for report)
Is 11.0.39rc6 earlier or later than 11.0.39? I ask, because with NoScript 11.0.39 in Tor Browser 9.5.3 (64-bit) on Windows 10 1909, I see the rapid page re-load issue when opening local TXT and HTML files. It goes away if I disable NoScript.

Re: Noscript puts FF in a reload loop

Posted: Sat Aug 22, 2020 8:55 pm
by Guest
Giorgio Maone wrote:
Fri Aug 21, 2020 7:50 pm
This seems to be fixed to me now (tested on 39rc8 and 40rc1). Please confirm, thanks.
Issue still persists on both 39rc8 and 40rc1 for me.

Re: Noscript puts FF in a reload loop

Posted: Sat Aug 22, 2020 9:10 pm
by musonius
FranL wrote:
Sat Aug 22, 2020 6:49 pm
with NoScript 11.0.39 in Tor Browser 9.5.3 (64-bit)
Yes indeed. I have the issue as well (Tor Browser: Safer Security Level).

Firefox 79 (fresh profile + NoScript 11.0.39 + everything default): no issue.

Firefox 79 (fresh profile + NoScript 11.0.39 + NoScript configuration like Tor Browser with Safer Security Level): no issue.

I am running Windows 10 2004 and I use the test file with Windows line endings like before.

Re: Noscript puts FF in a reload loop

Posted: Sat Aug 22, 2020 11:20 pm
by Giorgio Maone
It's a very different issue in Tor Browser, unfortunately, even though the effect is the same.
The Tor Browser erases window.name on each load, therefore completely screwing up current persistence hack.
It got very complicated at this point and I've been working for several hours on a further work-around, but I hope to have something by Monday.