In legacy/trac#27401 (moved) we fixed JavaScript being disabled in start-up and (I believe) the security slider not working.
However, testing with the second release candidate for Tor Browser 8 (https://people.torproject.org/~gk/builds/8.0-build4/) shows that this is (still) broken on Windows while at least on Linux it is working. On Windows both 32bit and 64bit bundles disabled JavaScript and the security slider is essentially not working.
Designs
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related.
Learn more.
In legacy/trac#27401 (moved) we moved adding the message listener to an earlier point during start-up as NoScript seemed to send its "startup" message before the listener got added. We chose the startup-observer and added the message listener essentially after receiving the profile-after-change notification. That fixed the problem on Linux and I think on macOS as well. However, on Windows we still hit this.
I see a message in the console indicating that the listener got set up. But we never reveice a message from NoScript. It seems we can't start the message handler much earlier, so I wonder what else we could do. Adding Giorgio, maybe he has some ideas.
Okay, I added the message listener earlier, into the constructor of one of our components. While the message listener is indeed called even earlier, that does not help for the Windows bundles. We still don't get a message from NoScript.
Looking closer at the log in the browser console I see the warnings related to web extensions loading indeed show up way later than all the XPCOM initialization foo as Giorgio indicates in
Anyway, if all the Tor Button initialization happens synchronously in a profile-after-change observer, like it was usually done in XUL extensions, it will definitely finish before NoScript starts.
(comment:39:ticket:26520).
So, I wonder whether something else breaks here on Windows.
So, I wonder whether something else breaks here on Windows.
I'm almost sure that the problem on Windows (which is gonna be a problem on Linux and Mac OS X in next ESR, but not yet), is that WebExtension's background pages on that platform already run in a separate process from the main browser on Firefox 60, while this feature is enabled on Mac OS X in 61 and on Linux in 63.
Therefore, even if you add the listener in profile-after-change (the correct and earliest place to do it), on Windows there's anyway an unpredictable latency due to IPC.
Anticipating the registration in a component costructor won't help, because it's too early to do anything meaningful with a specific extension, since we're not aware yet of the profile in use and therefore of the installed extensions.
IMHO the only way to be sure we manage to get in sync is NoScript knowing from the start that it's running in the Tor Browser (I suggested by customizing the browser.runtime.getBrowserInfo() API to return something meaningful, but maybe there's an easier way) and, if that's the case, either repeating the "start" message every 100ms until it gets acknowledged or waiting for an "updateSettings" message to arrive.
So, I wonder whether something else breaks here on Windows.
I'm almost sure that the problem on Windows (which is gonna be a problem on Linux and Mac OS X in next ESR, but not yet), is that WebExtension's background pages on that platform already run in a separate process from the main browser on Firefox 60, while this feature is enabled on Mac OS X in 61 and on Linux in 63.
Therefore, even if you add the listener in profile-after-change (the correct and earliest place to do it), on Windows there's anyway an unpredictable latency due to IPC.
Anticipating the registration in a component costructor won't help, because it's too early to do anything meaningful with a specific extension, since we're not aware yet of the profile in use and therefore of the installed extensions.
IMHO the only way to be sure we manage to get in sync is NoScript knowing from the start that it's running in the Tor Browser (I suggested by customizing the browser.runtime.getBrowserInfo() API to return something meaningful, but maybe there's an easier way) and, if that's the case, either repeating the "start" message every 100ms until it gets acknowledged or waiting for an "updateSettings" message to arrive.
Thanks for the explanation which makes sense to me. I agree we should develop an even more robust means of Tor Browser <-> NoScript communication. I fear this takes too long, though, to unblock our pending release. I wonder whether we can just disable that background scripts being in an own process on Windows for now... Is there a pref we can flip? Or potentially we can patch the source to do that, too...
IMHO the only way to be sure we manage to get in sync is NoScript knowing from the start that it's running in the Tor Browser (I suggested by customizing the browser.runtime.getBrowserInfo() API to return something meaningful, but maybe there's an easier way) and, if that's the case, either repeating the "start" message every 100ms until it gets acknowledged or waiting for an "updateSettings" message to arrive.
Something that now occurrs to me, which doesn't require any further patching of NoScript, is for torbutton to keep sending its first updateSettings message (say every 100 ms) until NoScript responds.
I pushed a commit to tor-browser-60.2.0esr-8.0-1 (commit 124fa904) that essentially sets extensions.webextensions.remote to false on all platforms to get the rebuild starting.
IMHO the only way to be sure we manage to get in sync is NoScript knowing from the start that it's running in the Tor Browser (I suggested by customizing the browser.runtime.getBrowserInfo() API to return something meaningful, but maybe there's an easier way) and, if that's the case, either repeating the "start" message every 100ms until it gets acknowledged or waiting for an "updateSettings" message to arrive.
Something that now occurrs to me, which doesn't require any further patching of NoScript, is for torbutton to keep sending its first updateSettings message (say every 100 ms) until NoScript responds.
But without a further, Tor Browser specific patch for NoScript (to delay page loads until the updateSettings message has arrived), the first page load could still happen with the wrong settings.
But without a further, Tor Browser specific patch for NoScript (to delay page loads until the updateSettings message has arrived), the first page load could still happen with the wrong settings.
That's an interesting point. But if NoScript is not ready when the first page load has happened, then doesn't that mean its settings won't be applied to that page anyway?
Edit: On further thought, I guess it is possible that when NoScript sends its "started" message, then reply will be too slow to catch it before NoScript's pre-adjusted settings are applied to the first page.
But without a further, Tor Browser specific patch for NoScript (to delay page loads until the updateSettings message has arrived), the first page load could still happen with the wrong settings.
That's an interesting point. But if NoScript is not ready when the first page load has happened, then doesn't that mean its settings won't be applied to that page anyway?
First thing NoScript does, before any asynchronous initialization and hopefully before any page load (at least it seems to be working reliably even with session restore pages) is suspending any web loading activity until it's actually ready to enforce policies.
Edit: On further thought, I guess it is possible that when NoScript sends its "started" message, then reply will be too slow to catch it before NoScript's pre-adjusted settings are applied to the first page.
That should not be the case, because NoScript waits for the response before resuming web loading activity.