InformAction Forums

I've finally managed to reproduce it, only by adding about a thousand whitespaces before the
<meta http-equiv="content-type" content= "text/html; charset=us-ascii">
element.
Did you omit the whitespace when pasting or it is actually not there in your samples?
Or maybe there's something in your configuration preventing the charset declaration from being "seen" in the first 1024 bytes of the file?!
Investigating how to work-around this hairy problem anyway, thanks.

@musonius: do you mean you get reload loops as well?

Giorgio Maone wrote: ↑Wed Aug 19, 2020 7:30 pm @musonius: do you mean you get reload loops as well?

Yes. I saved the HTML code as it is without changing anything, created (and started) a new profile and installed the current dev version NoScript (11.0.39rc5). When I opened the file per drag and drop I got the reload loops immediately.

How mysterious.

And for comparison, with .96 and that same file, I get this in the browser console

Key event not available on some keyboard layouts: key=“i” modifiers=“accel,alt,shift” id=“key_browserToolbox” browser.xhtml
Key event not available on some keyboard layouts: key=“i” modifiers=“accel,alt,shift” id=“key_browserToolbox” browser.xhtml
TypeError: MutationObserver.observe: Argument 1 is not an object. collectFormData.js:996:21
Promise resolved after context unloaded
content.js:39
Promise resolved after context unloaded
content-script.js:21
Promise resolved after context unloaded
socialwidgets.js:512
Promise rejected after context unloaded:
2 Messages.js:67
Key event not available on some keyboard layouts: key=“i” modifiers=“accel,alt,shift” id=“key_browserToolbox” browser.xhtml

(@bernie, your tracking id is valid, if that matters to you)

After preventing the Web Console to clear the logs I can see the following entries again and again:
In a fresh profile with 11.0.37 I get this:

It actually looks to be the break in this line that is doing it (not necessarily 1024 spaces):
Now don't know if OP's actual source has the break, or only when he copied it in here.
In any case, broken, it loops.
Break removed, OP's version is fine.


Heh, I might be wrong about that...

therube wrote: ↑Wed Aug 19, 2020 8:03 pm It actually looks to be the break in this line that is doing it (not necessarily 1024 spaces):

Yes indeed. I do not get the reload loop without the break either.

musonius wrote: ↑Wed Aug 19, 2020 8:06 pm

therube wrote: ↑Wed Aug 19, 2020 8:03 pm It actually looks to be the break in this line that is doing it (not necessarily 1024 spaces):

Yes indeed. I do not get the reload loop without the break either.

Yes! Interestingly enough, it must be a CRLF: I did not get the loop until I added the 1024 bytes (not necessarily spaces) as suggested by the error messages because I'm on Linux, and therefore the break being just a LF didn't... break the charset parsing.
This looks like a legitimate Gecko bug, even though the main issue (the page entering a reload loop if the charset can't be parsed in the first 1024 bytes) still needs to be worked around.

I can reproduce this with NoScript 11.0.39rc5 + Firefox 79.0 on Windows 10, with that exact sample file. Completely default settings for both Firefox & NoScript here.

Not reproducible on Linux.

EDIT Oops, collided posting with Giorgio. Yes when pasting in Windows it used CRLF for line endings.

Please check latest development build:

v 11.0.39rc6
============================================================
x Fix reload loops on broken file: HTML documents (thanks
bernie for report)
x [XSS] Updated HTML event attributes

Works like a charm. Thanks!!

Giorgio Maone wrote: ↑Wed Aug 19, 2020 10:28 pm Please check latest development build:

v 11.0.39rc6
============================================================
x Fix reload loops on broken file: HTML documents (thanks
bernie for report)
x [XSS] Updated HTML event attributes

(These changes and the 11.0.39rc6 tag are missing from Github, and the master branch is outdated.)

barbaz wrote: ↑Thu Aug 20, 2020 2:16 am

Giorgio Maone wrote: ↑Wed Aug 19, 2020 10:28 pm Please check latest development build:

v 11.0.39rc6
============================================================
x Fix reload loops on broken file: HTML documents (thanks
bernie for report)
x [XSS] Updated HTML event attributes

(These changes and the 11.0.39rc6 tag are missing from Github, and the master branch is outdated.)

Fixed, thanks.

No reload loop anymore!

11.0.39rc6 on linux. Can't reproduce the original bug with any config, so not able to say anything about how the fix handles that, BUT...

While changing permissions on any file, the permissions are not always actually changed after the reload.

This would appear to be caused by the onBeforeUnload not being removed correctly on DOMContentLoaded, which will cause the old permissions to be set after reloading.

But before you rush to fix it, consider also this example:
User could allow scripts, get the popup and immediately decide to disallow them again, which would result in a reload happening before DOMContentLoaded, onBeforeUnload running, the old permissions being set again and another popup, even if the removing of onBeforeUnload is fixed in DOMContentLoaded.

Also the timestamp in the key will eventually (with some bad luck or persistence) cause the policy to be left in the window.name. Is the timestamp necessary?