Opened 3 months ago

Closed 4 weeks ago

Last modified 3 weeks ago

#26520 closed defect (fixed)

NoScript is broken with TOR_SKIP_LAUNCH=1 in ESR 60-based Tor Browser

Reported by: gk Owned by: pospeselr
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: ff60-esr, TorBrowserTeam201808R, noscript, AffectsTails
Cc: arthuredelstein, mcs, brade, rustybird@…, intrigeri, tbb-team, ma1 Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

rustybird reported that NoScript is broken when setting TOR_SKIP_LAUNCH=1 (see comment:13:ticket:26128):
"""
This seems to break on a fresh 8.0a9-build3 linux64 installation whenever TOR_SKIP_LAUNCH=1 is set (with system tor
running on the usual ports). JavaScript is effectively disabled and the browser console says:

[06-25 18:36:50] Torbutton NOTE: security-prefs.js initialization complete
Error: Could not establish connection. Receiving end does not exist. ExtensionCommon.jsm:456:12

Some sort of extension startup race?
"""

Child Tickets

Attachments (5)

debug-retry.diff (1.9 KB) - added by rustybird 5 weeks ago.
noscript-NoScript.started.diff (415 bytes) - added by rustybird 5 weeks ago.
torbutton-NoScript.started.diff (883 bytes) - added by rustybird 5 weeks ago.
v2-noscript-started.diff (398 bytes) - added by rustybird 4 weeks ago.
supersedes noscript-NoScript.started.diff [and added semicolon]
arthuredelstein-26520+1-rebased.patch (4.9 KB) - added by rustybird 4 weeks ago.

Download all attachments as: .zip

Change History (56)

comment:1 Changed 3 months ago by rustybird

Just to clarify: NoScript itself doesn't appear to be broken - only the communication between Torbutton and NoScript.

Last edited 3 months ago by rustybird (previous) (diff)

comment:2 Changed 3 months ago by arthuredelstein

Thanks, rustybird! I can reproduce this. The cause of the reported error is that NoScript starts (or at least starts listening for messages) later than torbutton tries to send initial settings. Unfortunately I haven't figured out yet how to determine when NoScript is ready to receive messages.

Last edited 3 months ago by arthuredelstein (previous) (diff)

comment:3 Changed 3 months ago by intrigeri

Cc: intrigeri added

comment:4 Changed 3 months ago by gk

Keywords: TorBrowserTeam201807 added; TorBrowserTeam201806 removed

Moving first batch of tickets to July 2018

comment:5 Changed 2 months ago by arthuredelstein

Keywords: TorBrowserTeam201807R added; TorBrowserTeam201807 removed
Status: newneeds_review

comment:6 Changed 2 months ago by rustybird

Here's a patch for review:
https://github.com/arthuredelstein/torbutton/commit/26520

Now it seems to fire too late - on first site load (not including about:tor). If that first loaded site contains JavaScript, it will be disabled there. Tested on e.g. https://enable-javascript.com

I tried with a line log(5, "XXX sending"); added inside the sendNoScriptSettings function and noticed that both the first site load and moving the slider resulted in multiple messages to NoScript - not sure if that's a problem. (Slightly related, noscript-control.js has a guard against the initialized variable, but it's never set to true.)

log(e.message); -> log(5, e.message);

comment:7 in reply to:  6 Changed 2 months ago by arthuredelstein

Replying to rustybird:

Thanks for testing! Addressing your comments in rearranged order:

(Slightly related, noscript-control.js has a guard against the initialized variable, but it's never set to true.)

log(e.message); -> log(5, e.message);

Thanks for catching these two mistakes. Here's a revised patch that includes fixes for those:
https://github.com/arthuredelstein/torbutton/commit/26520+1

Now it seems to fire too late - on first site load (not including about:tor). If that first loaded site contains JavaScript, it will be disabled there. Tested on e.g. https://enable-javascript.com

I tried with a line log(5, "XXX sending"); added inside the sendNoScriptSettings function and noticed that both the first site load and moving the slider resulted in multiple messages to NoScript - not sure if that's a problem.

I wasn't able to reproduce these two issues. I even tried setting https://enable-javascript.com as the browser's homepage, but in every case the NoScript state seems to be set correctly. Do you still see these issues with the revised patch?

comment:8 Changed 2 months ago by rustybird

I wasn't able to reproduce these two issues.

The "multiple messages to NoScript" problem is gone with the revised patch. I still have the "first site load" problem on a freshly extracted and patched TB - sorry if it's tediously verbose:

  1. Run system tor on SocksPort 9150, ControlPort 9151
  2. Extract tor-browser-linux64-8.0a9_en-US.tar.xz to a new directory
  3. In the extensions directory, unzip -d torbutton@torproject.org/ torbutton@torproject.org.xpi and delete the .xpi
  4. In torbutton@torproject.org/, apply the revised patch with -p2
  5. Make a backup of the pristine patched tor-browser_en-US/ directory
  6. Run TOR_SKIP_LAUNCH=1 ./start-tor-browser.desktop
  7. Go to https://enable-javascript.com

It shows "JavaScript is disabled in your web browser" until I refresh the site, at which point it switches to "JavaScript is enabled". Same for other websites that depend on JavaScript, e.g. https://twitter.com/torproject (after restarting with a new copy of the backed up directory from step 5).

comment:9 Changed 2 months ago by gk

Keywords: TorBrowserTeam201807 added; TorBrowserTeam201807R removed
Status: needs_reviewneeds_revision

comment:10 Changed 8 weeks ago by gk

Keywords: TorBrowserTeam201808 added; TorBrowserTeam201807 removed

Move our tickets to August.

Changed 5 weeks ago by rustybird

Attachment: debug-retry.diff added

comment:11 Changed 5 weeks ago by rustybird

@arthuredelstein: As an experiment, I added a patch (debug-retry.diff) on top of your second patch. It reverts to the previous approach of immediately calling sendMessage() instead of waiting for a message from NoScript first, and it also retries on failure. Weirdly, after logging about ten failures and then a success to the Browser Console, JavaScript is still disabled! (On a fresh TB installation.) Maybe there's a second race condition somewhere, e.g. NoScript ignoring a message delivered successfully but very early?

BTW should this ticket have the AffectsTails keyword?

comment:12 in reply to:  11 ; Changed 5 weeks ago by intrigeri

Replying to rustybird:

BTW should this ticket have the AffectsTails keyword?

Thanks for caring! Tails does not use TOR_SKIP_LAUNCH=1. Instead we set TOR_CONFIGURE_ONLY=1 before starting Tor Launcher (as an independent XUL application). I've tested on my current build of Tails with Tor Browser 8.0a10 and:

  • NoScript seems to work just fine
  • I see JavaScript error: resource://gre/modules/ExtensionCommon.jsm, line 456: Error: Could not establish connection. Receiving end does not exist. in the logs.
  • If I raise the security slider to "Safest" then JavaScript is correctly disabled.
  • I don't know how to test whether "the communication between Torbutton and NoScript" works.

Let me know if there's any other info I can provide, happy to help :)

comment:13 in reply to:  12 ; Changed 5 weeks ago by rustybird

Replying to intrigeri:

Tails does not use TOR_SKIP_LAUNCH=1. Instead we set TOR_CONFIGURE_ONLY=1 before starting Tor Launcher (as an independent XUL application).

I think it's equivalent for this bug (except with maybe a slightly different timing in the race?) to use TOR_SKIP_LAUNCH=1, or extensions.torlauncher.start_tor=false, or to completely disable/remove the TorLauncher extension in the main Tor Browser profile (e.g. because you're starting it independently).

  • I see JavaScript error: resource://gre/modules/ExtensionCommon.jsm, line 456: Error: Could not establish connection. Receiving end does not exist. in the logs.

Yup, there it is. :\

  • If I raise the security slider to "Safest" then JavaScript is correctly disabled.
  • I don't know how to test whether "the communication between Torbutton and NoScript" works.

The symptom to look out for is JavaScript not working on websites even though it should be enabled, especially in the default state after installation. If you start a fresh browser and don't open the Torbutton Security Settings dialog at all, the slider level defaults to Standard, so JavaScript should be enabled - but:

  • situation on vanilla 8.0a9 and 8.0a10: You can only make JavaScript work if you move the slider away from Standard to Safer or Safest, confirm with OK, and then move it back to Standard again
  • situation with the proposed second patch: JavaScript only works (and the slider only becomes functional) after the first website has been loaded

Changed 5 weeks ago by rustybird

Changed 5 weeks ago by rustybird

comment:14 in reply to:  11 Changed 5 weeks ago by rustybird

Replying to rustybird:

Maybe there's a second race condition somewhere, e.g. NoScript ignoring a message delivered successfully but very early?

Looks like my debug-retry.diff sends the settings so early that NoScript will clobber them during its own startup. I've attached two new patches that ensure the message is sent at the right time, neither too soon nor too late:

  • noscript-NoScript.started.diff, if applied to NoScript (unix2dos < noscript-NoScript.started.diff | patch --binary -p2 inside an unpacked NoScript extension directory) makes it broadcast a NoScript.started type message after it has initialized. If someone wants to test it, don't forget to disable signature verification for the modified NoScript extension, e.g. by flipping the xpinstall.signatures.required pref to false.
  • torbutton-NoScript.started.diff, if applied to Torbutton (on top of arthuredelstein's second patch), waits for exactly that message.

Thoughts?

comment:15 in reply to:  13 ; Changed 5 weeks ago by intrigeri

Replying to rustybird:

Replying to intrigeri:

  • I don't know how to test whether "the communication between Torbutton and NoScript" works.

The symptom to look out for is JavaScript not working on websites even though it should be enabled, especially in the default state after installation. If you start a fresh browser and don't open the Torbutton Security Settings dialog at all, the slider level defaults to Standard, so JavaScript should be enabled - but:

  • situation on vanilla 8.0a9 and 8.0a10: You can only make JavaScript work if you move the slider away from Standard to Safer or Safest, confirm with OK, and then move it back to Standard again

Thanks for the detailed explanation :)

OK, so in Tails the browser homepage is https://tails.boum.org/home/. It does use JavaScript sometimes, and thankfully for the purpose of debugging this problem, we're currently in the (rather rare) situation where it does run some JS in a way that can trivially be noticed. So I could confirm that this piece of JS does run just fine on our homepage when starting Tor Browser 8.0a10 in Tails. Then, FWIW, I immediately set the security slider to "safest", reloaded the home page, and confirmed that our JS was not run this time. So I think the use cases we care about at Tails are not affected => no need for an AffectsTails keyword.

comment:16 in reply to:  15 ; Changed 5 weeks ago by rustybird

Replying to intrigeri:

So I could confirm that this piece of JS does run just fine on our homepage when starting Tor Browser 8.0a10 in Tails.

And the Could not establish connection. Receiving end does not exist. error from ExtensionCommon.jsm still appeared when you observed working JS? Sorry for pestering you, it's just baffling.

comment:17 in reply to:  16 ; Changed 5 weeks ago by intrigeri

Replying to rustybird:

Replying to intrigeri:
And the Could not establish connection. Receiving end does not exist. error from ExtensionCommon.jsm still appeared when you observed working JS?

Yes (I've just tested again just to be sure).

Sorry for pestering you, it's just baffling.

No problem!

comment:18 Changed 5 weeks ago by pospeselr

Owner: changed from tbb-team to pospeselr
Status: needs_revisionassigned

comment:19 Changed 5 weeks ago by boklm

Cc: tbb-team added

comment:20 Changed 5 weeks ago by gk

Keywords: noscript added

comment:21 Changed 4 weeks ago by gk

Priority: Very HighHigh
Status: assignedneeds_information

rustybird: Are things still broken for you using the latest Tor Browser nightly (http://f4amtbsowhix7rrf.onion/tor-browser-builds/)? (make sure to update NoScript first, before doing your testing)

comment:22 in reply to:  21 Changed 4 weeks ago by rustybird

Replying to gk:

rustybird: Are things still broken for you using the latest Tor Browser nightly (http://f4amtbsowhix7rrf.onion/tor-browser-builds/)? (make sure to update NoScript first, before doing your testing)

Yes, the 2018-08-25 Tor Browser nightly, with NoScript manually updated to 10.1.8.23 before first start and Torbutton patched with the fix for #27276, is broken in the same way as before.

comment:23 in reply to:  17 ; Changed 4 weeks ago by rustybird

Replying to intrigeri:

Replying to rustybird:

And the Could not establish connection. Receiving end does not exist. error from ExtensionCommon.jsm still appeared when you observed working JS?

Yes (I've just tested again just to be sure).

I tried it out with tails-amd64-feature_15803-tor-browser-8.0a10+force-all-tests-3.9-20180819T1720Z-575956dc62+testing@b05edb901d.iso (apparently deleted from https://nightly.tails.boum.org/ in the meantime):

Torbutton 2.0.2 from Tor Browser 8.0a10 does not have the initialized = true fix yet, so sendMessage() happens to be called twice on init. The first time it fails with the error message, the second time it succeeds for me. Same as you, apparently. Maybe my old test notebook causes delays in just the right order before the second sendMessage(), giving NoScript time to become ready? Whereas with vanilla 8.0a10 in my Fedora 28 test VM, both sendMessage() calls fail and I see the error twice.

With the Torbutton fix (included in Torbutton >= 2.0.4), the bug does seem to consistently affect Tails in my testing.

comment:24 in reply to:  23 ; Changed 4 weeks ago by intrigeri

Replying to rustybird:

I tried it out with tails-amd64-feature_15803-tor-browser-8.0a10+force-all-tests-3.9-20180819T1720Z-575956dc62+testing@b05edb901d.iso (apparently deleted from https://nightly.tails.boum.org/ in the meantime):

FYI that's because the corresponding topic branch was merged into our testing branch so our CI stopped building it and GC'ed the now obsolete artifacts. Until Tails 3.9 is out, https://nightly.tails.boum.org/build_Tails_ISO_testing/lastSuccessful/archive/build-artifacts/ is the closest thing to what we'll release.

With the Torbutton fix (included in Torbutton >= 2.0.4), the bug does seem to consistently affect Tails in my testing.

Thanks for testing & reporting! I'll reproduce this and will assess how problematic this is for Tails (hopefully today or tomorrow).

comment:25 in reply to:  24 Changed 4 weeks ago by intrigeri

Replying to intrigeri:

Replying to rustybird:
Thanks for testing & reporting! I'll reproduce this and will assess how problematic this is for Tails (hopefully today or tomorrow).

Here are my test results on current Tails testing branch. Thanks to gk for the guidance!

  • no change: cannot reproduce
  • upgrade Torbutton to a XPI built from commit c93f06417e0bdbd6d709ec5109938347d1d38123 with ./makexpi.sh: reproduced the bug; all pages are affected, not only the 1st loaded one
  • upgrade Torbutton to a XPI built from commit c93f06417e0bdbd6d709ec5109938347d1d38123 with ./makexpi.sh, upgrade NoScript to https://secure.informaction.com/download/releases/noscript-10.1.8.23.xpi: reproduced the bug; all pages are affected (not only the 1st loaded one) until I do the trick gk suggested i.e. set the security slider to safer, apply, set the security slider back to standard, apply.

Anyone who wants to reproduce this or try to fix it in the context of Tails:

  • grab an ISO from https://nightly.tails.boum.org/build_Tails_ISO_testing/lastSuccessful/archive/build-artifacts/
  • boot that ISO in a x86-64 VM with at least 2GB of RAM
  • in the Tails Greeter ("Welcome to Tails"), set an administration password so you can use sudo in the next step: click the "+" button, click "Administration Password", etc.
  • replace whatever XPI you want: they live in /usr/local/share/tor-browser-extensions
  • start tor-browser from a terminal to see its stdout (otherwise it's sent to the systemd Journal that you can query with sudo journalctl).

I'm happy to provide more guidance or to test stuff myself in the context of Tails :)

comment:26 Changed 4 weeks ago by rustybird

Okay, I've updated my one-liner NoScript patch (that makes it send a "started" message) to its new messaging system - this is v2-noscript-started.diff​ and it supersedes noscript-NoScript.started.diff​. See comment:14 for how to apply it to an unpacked NoScript extension directory. I'm going to open a NoScript pull request if nobody objects, maybe it can land in time for the Tor Browser 8.0 release.

As for my other patch, torbutton-NoScript.started.diff, on second thought I think it shouldn't be applied. Because in the unlikely case that the NoScript WebExtension finishes startup sooner than the unbootstrapped XPCOM Torbutton extension, which would mean that Torbutton (patched with arthuredelstein's proposed +1 patch rebased on top of aa379dc) misses the "started" message, it would be a more graceful failure mode to at least submit the slider settings after the first webpage has loaded and NoScript has sent a non-"started" message (instead of never submitting the slider settings at all). NoScript currently doesn't seem to send any messages before its own initialization phase has finished, so it wouldn't clobber the configuration (see comment:11) if Torbutton just reacts to the first message, whatever it may be.

To summarize, IMHO Tor Browser 8.0 final should ship with:

As far as I can tell, this allows an escape from the maze of race conditions...

Last edited 4 weeks ago by rustybird (previous) (diff)

Changed 4 weeks ago by rustybird

Attachment: v2-noscript-started.diff added

supersedes noscript-NoScript.started.diff [and added semicolon]

comment:27 Changed 4 weeks ago by gk

Cc: ma1 added

Giorgio, does comment:26 sound like a good idea to you?

comment:28 in reply to:  27 Changed 4 weeks ago by ma1

Replying to gk:

Giorgio, does comment:26 sound like a good idea to you?

Yes, it makes sense. I'm gonna accept the PR as soon as I get it notified.

comment:29 Changed 4 weeks ago by rustybird

Last edited 4 weeks ago by rustybird (previous) (diff)

comment:30 in reply to:  29 ; Changed 4 weeks ago by ma1

comment:31 in reply to:  30 ; Changed 4 weeks ago by gk

Status: needs_informationnew

Replying to ma1:

Replying to rustybird:

https://github.com/hackademix/noscript/pull/16

Merged, thanks.

Great, thanks. Giorgio, could you get a new NoScript version out, let's say on Wednesday european time, including this fix? We thought about starting building Tor Browser 8 on that evening and Tails needs that one as they don't have extensions updates enabled.

Changed 4 weeks ago by rustybird

comment:32 in reply to:  31 Changed 4 weeks ago by ma1

Replying to gk:

Replying to ma1:

Replying to rustybird:

https://github.com/hackademix/noscript/pull/16

Merged, thanks.

Great, thanks. Giorgio, could you get a new NoScript version out, let's say on Wednesday european time, including this fix?

All right, can you start testing 10.1.9rc2, which includes this patch.

comment:33 in reply to:  26 ; Changed 4 weeks ago by arthuredelstein

Many thanks to rustybird, Giorgio and intrigeri for your work on this!

Replying to rustybird:

in the unlikely case that the NoScript WebExtension finishes startup sooner than the unbootstrapped XPCOM Torbutton extension

Do we know for sure that NoScript loading first is unlikely? I'm not actually sure about what determines the order of XPIs loading.

If we wanted to be absolutely sure, NoScript could be patched to listen for a "ping" and reply with a "pong". And then torbutton could repeatedly send "ping" (say, once a second) until it receives a "pong", and then proceed by sending the first updateSettings message.

Giorgio, would that sort of patch sound reasonable to you? If so, I can send a pull request.

comment:34 in reply to:  33 ; Changed 4 weeks ago by ma1

Replying to arthuredelstein:

Do we know for sure that NoScript loading first is unlikely? I'm not actually sure about what determines the order of XPIs loading.

If your XPI is a bootstrapped (legacy) extensions and does all its initialization in its startup callback yes, it's impossible for NoScript to be initialized first: WebExtensions are loaded asynchronously, most if not all the WebExtensions APIs are asynchronous as well. As a matter of facts, NoScript needs some ugly hacks (like blocking and reloading pages retrieved from session restore) in order not reliably enforce its policy on startup (see deferredWebTraffic.js).

If we wanted to be absolutely sure, NoScript could be patched to listen for a "ping" and reply with a "pong". And then torbutton could repeatedly send "ping" (say, once a second) until it receives a "pong", and then proceed by sending the first updateSettings message.

Giorgio, would that sort of patch sound reasonable to you? If so, I can send a pull request.

Not knowing what kind of (possibly asynchronous) work you're doing on your side before you're ready, I'm willing to check a patch, provided that it doesn't break other clients different than the Tor Browser.

comment:35 Changed 4 weeks ago by intrigeri

FWIW I've tested Tails (testing branch i.e. 8.0a10) + Torbutton built from commit c93f06417e0bdbd6d709ec5109938347d1d38123 + NoScript 10.1.9rc2 and I can still reproduce the bug for all pages (not just the 1st loaded one). The security slider back'n'forth trick "fixes" it.

comment:36 Changed 4 weeks ago by gk

Alright, I uploaded a Torbutton .xpi containing the fix on top of master for easier testing:

https://people.torproject.org/~gk/misc/torbutton-2.0.4.xpi
https://people.torproject.org/~gk/misc/torbutton-2.0.4.xpi.asc

comment:37 Changed 4 weeks ago by intrigeri

Tails (testing branch i.e. 8.0a10) + the Torbutton 2.0.4 XPI uploaded by gk + NoScript 10.1.9rc2: the bug is fixed! \o/ :)

comment:38 in reply to:  34 ; Changed 4 weeks ago by rustybird

Replying to ma1:

If your XPI is a bootstrapped (legacy) extensions and does all its initialization in its startup callback yes, it's impossible for NoScript to be initialized first

Torbutton as an unbootstrapped / XUL overlay flavor of legacy extension should load even earlier, right? Although I'm unfamiliar with Torbutton's startup and don't know about the potential async initialization work you mentioned.

Replying to arthuredelstein:

If we wanted to be absolutely sure, NoScript could be patched to listen for a "ping" and reply with a "pong". And then torbutton could repeatedly send "ping" (say, once a second) until it receives a "pong", and then proceed by sending the first updateSettings message.

Sounds like an improvement. And if Torbutton accepts both "start" and the first "pong", there wouldn't even be an up to 1 second delay (which might be a problem if a URL is loaded quickly after browser startup, e.g. a non-about: homepage). Edit: Although even with both "start" and "ping"/"pong", AFAICT it's still not 100% certain that the updateSettings message is sent and handled before the first page is loaded...

Last edited 4 weeks ago by rustybird (previous) (diff)

comment:39 in reply to:  38 ; Changed 4 weeks ago by ma1

Replying to rustybird:

Although even with both "start" and "ping"/"pong", AFAICT it's still not 100% certain that the updateSettings message is sent and handled before the first page is loaded...

Well, IMHO the most reliable way to do it, no matter how long initialization takes on both sides, could be this:

1) NoScript needs a way to know very early (at the beginning of its execution) that it's running in the Tor Browser.
Ideally, the browser.runtime.getBrowserInfo() API should return something unique, like {name: "Tor Browser", vendor: "The Tor Project"} (not sure if this requires a patch to the WebExtensions API or just setting some preference).

2) If it knows it's hosted by TB, NoScript will run its initialization code, including the part where it defers all the content network activity until ready, but won't unblock until a specific "updateSettings" message is received from the Tor Browser.

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.

Therefore, if this is the case, NoScript waiting for the "start" message to be answered (like in the original patch) should suffice, provided that this happens before we resolve the init() promise and give the green light to deferWebTraffic: hence my just released 10.1.9rc3 which reorders NoScript's startup sequence to guarantee this. Please test it.

comment:40 in reply to:  39 ; Changed 4 weeks ago by rustybird

Replying to ma1:

Well, IMHO the most reliable way to do it, no matter how long initialization takes on both sides, could be this:

1) NoScript needs a way to know very early (at the beginning of its execution) that it's running in the Tor Browser.
Ideally, the browser.runtime.getBrowserInfo() API should return something unique, like {name: "Tor Browser", vendor: "The Tor Project"} (not sure if this requires a patch to the WebExtensions API or just setting some preference).

2) If it knows it's hosted by TB, NoScript will run its initialization code, including the part where it defers all the content network activity until ready, but won't unblock until a specific "updateSettings" message is received from the Tor Browser.

I don't understand the Firefox/Torbutton/NoScript innards enough to say if that's the way to go, though it sounds like the most solid solution. Hopefully someone will weigh in. But with the Tor Browser 8.0 final release just around the corner, fingers crossed that the interim solution can hold the line. :)

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.

Therefore, if this is the case, NoScript waiting for the "start" message to be answered (like in the original patch) should suffice, provided that this happens before we resolve the init() promise and give the green light to deferWebTraffic: hence my just released 10.1.9rc3 which reorders NoScript's startup sequence to guarantee this. Please test it.

Tor Browser 8.0a10 + NoScript 10.1.9.rc3 + the Torbutton .xpi from gk's comment:36 seem to work well in my Fedora 28 test VM. Thank you! Might be worth testing in Tails again too, given the previous weird timing differences.

comment:41 in reply to:  40 Changed 4 weeks ago by arthuredelstein

Replying to rustybird:

Tor Browser 8.0a10 + NoScript 10.1.9.rc3 + the Torbutton .xpi from gk's comment:36 seem to work well in my Fedora 28 test VM. Thank you! Might be worth testing in Tails again too, given the previous weird timing differences.

These worked well for me on Ubuntu as well, both with and without TOR_SKIP_LAUNCH. If this combination works on TAILS, I agree we should stick with it for the upcoming release.

comment:42 in reply to:  31 ; Changed 4 weeks ago by ma1

Replying to gk:

Great, thanks. Giorgio, could you get a new NoScript version out, let's say on Wednesday european time

All right, we're currently at rc6 and I hope to keep beta people there testing a bit for another 18 hours or so, then release (Wednesday evening UTC) 10.1.9 for Tor Browser inclusion.
Does it sound good for you?

comment:43 in reply to:  42 Changed 4 weeks ago by gk

Replying to ma1:

Replying to gk:

Great, thanks. Giorgio, could you get a new NoScript version out, let's say on Wednesday european time

All right, we're currently at rc6 and I hope to keep beta people there testing a bit for another 18 hours or so, then release (Wednesday evening UTC) 10.1.9 for Tor Browser inclusion.
Does it sound good for you?

Yes!

comment:44 Changed 4 weeks ago by gk

intrigeri: see comment:40 if you have time.

comment:45 in reply to:  40 Changed 4 weeks ago by intrigeri

Replying to rustybird:

Replying to ma1:
Tor Browser 8.0a10 + NoScript 10.1.9.rc3 + the Torbutton .xpi from gk's comment:36 seem to work well in my Fedora 28 test VM. Thank you! Might be worth testing in Tails again too, given the previous weird timing differences.

Works well on Tails too! Thanks to everyone who helped report, debug and fix this problem :)

comment:46 Changed 4 weeks ago by gk

Keywords: TorBrowserTeam201808R added; TorBrowserTeam201808 removed
Resolution: fixed
Status: newclosed

Alright, I pushed Arthur's patch to master (commit 931f0659c42fe317fd8ccae0d9210f8814dcf8ea). Fingers crossed and big thanks to everyone who helped here.

comment:47 Changed 4 weeks ago by gk

Keywords: AffectsTails added

comment:48 Changed 4 weeks ago by ma1

NoScript 10.1.9 stable just released.
Have a nice... whatever is appropriate in your TZ :)

comment:49 Changed 3 weeks ago by ma1

Ehy, just in case you did not merge it yet, 10.1.9.1 has a zero-risk patch which I guess is of particular interest for Tor/Tails, since I guess private browsing windows are the likely norm, rather than the exception.

comment:50 Changed 3 weeks ago by gk

Thanks for the heads-up! Works for us as we are still waiting for the 60.2.0esr candidate builds to start our own ones.

comment:51 Changed 3 weeks ago by cypherpunks3

One noted regression: Click-to-play for local videos (file://) no longer seems to work (tested on TB 8.0a10).

Note: See TracTickets for help on using tickets.