Managed to reproduce on another Mac (M1 running MacOS 11 Big Sur) that's never had Tor Browser installed on it before last night. Have now reproduced on three machines, including Intel and M1 on macs running both MacOS 11 and 12.
@championquizzer & @gus: we haven't been able to figure out how to definitively reproduce this issue, or what's causing it. Just a heads up that I suspect MacOS users will run into it in the wild after TB11 stable releases next week.
It seems to clear itself after relaunching the app one or multiple times, and doesn't reoccur thereafter.
It seems to clear itself after relaunching the app one or multiple times, and doesn't reoccur thereafter.
I also get the torconnect-buttons missing on Windows - it happens when I cold-boot TB 100% reliably - so some sort of timing issue? I can reproduce at will. I do have the tor-settings page but minus the connect button
Thanks @thorin, this is helpful. It looks like the tor process is 1) starting up very slowly, 2) doesn't start and Tor Browser doesn't notice it crashed (?), or 3) isn't configured correctly with the control port. Can you see if there is a tor process running when you experience this issue?
We could hit this if Tor Launcher hits it's 5 minute time out, but I did not see that happen, and that should cause obvious error messages which I did not see. However, I did see a temporary hang of ~30 second at startup where the browser was completely frozen, but then it recovered and showed a broken about:torconnect.
I also killed the tor process, so I could get a look at tor launcher's state:
The fact that mDidConnectToTorControlPort is true means that this.mObsSvc.notifyObservers(null, "TorProcessIsReady", null); should've been called, and that means that TorConnect should've moved into the Configuring state.
I don't know if this helps, but I can reproduce the bug 100% reliably (even after clearing it) by adding a random proxy address to about:preferences#tor and relaunching the application.
A Win7 user on IRC has reported experiencing something very similar:
> Whenever I start the tor browser (on windows 7) it hangs on the 'Connect to tor' screen.> the 'Always connect automatically' box is shown (ticked), but NOT the [Connect] button, and it doesn't connect> I have found a workaround as follows.> If I manually edit prefs.js and set 'sanity-test.webrender.force-disabled' to true, then the tor browser will run and connect as usual. > This value however is always set back to false when the browser is closed. This started happening around 20th Nov.> ...and i've seen no error messages. It just hangs.> one other bit of possibly pertinent info.. I use the Windows 7 system always via a 'remote utilities' remote login.> the system is on the local gigabit network, but in another room.> I figured it out first by installing a fresh copy of the tor browser, and then by a LOT of trial and error. An initial install works, but only the fist time.> so i then wrote a script to reset all files back to as-installed. (mostly deletion of cache dirs etc). and prefs.js...> i found just deleting prefs.js fixed the issue, so then I isolated the issue to this specific setting within prefs.js
I confirmed with the user that they are indeed referring to the pre-connection Connect to Tor screen – rather than Establishing a Connection – when they describe the connection hanging.
@thorin can you still reproduce this? If so would you mind posting the entire console log?
@duncan the symptoms you're seeing when setting a bad proxy is unrelated and easy enough to fix (the TorProtocolService.writeSettings() call is throwing which prevents the subsequent notification topic from going out so TorConnect is left waiting).
<donuts> any idea why this only seemed to become an issue in esr91?<GeKo> yeah, that would be one of my questions, too :)<richard> yeah<richard> so part of the work for esr91 was converting synchrynous socket IO to async<richard> we used to have 2 tor-controller implementations, one in tor-launcher and one in torbutton<richard> i guess the torbutton implementation looked easier to convert so we converted it to use async (or it already was, not sure on the details here)<richard> so now tor-launcher and torbutton now both use the torbutton control port implementation<richard> the problem is that almost every system using the control port expect tor to be running by the time they are running<richard> well taht wasn't the root problem, but that was some fallout i've also had to fix<richard> the 'root' problem is that if tor launched slowly, tor-launcher's initial connection attempt to the control port socket would fail<richard> we had naively passed in a simple 'throw error' error handler into the implementation, thinking that exception would bubble up in the event of a problem, signaling tor-launcher to try again later<richard> unfortunately, that exception was not being thrown up the same call stack, because the handler got passed into a separate native calling context <richard> so the exception would just throw and print to console, and our 'await torcontroller' call would just sit and block indefinitely<richard> but fixing that exposed the above mentioned 'all our code expects tor to be running when we make our control port' problem<richard> so i've also had to go an async'ify various other systems as well<richard> but now we can arbitrarily block tor from launching and everythign figures their shit out so yay
For run, you can also exacerbate the tor slow launch by adding extensions.torlauncher.launch_delay as a Number pref in about:config, the value being number of milliseconds to delay before initiating the tor daemon launch.
On first run (before profile is created, the launch was instantaneous and the connect button was there)
Setting the pref to e.g. a 5 second delay, simulated the long wait for a connect button no console errors (edit buttin shows up, I can connect, I can browser). I'll check later after a reboot, to see what happens without the artificial delay
here's the log with 5 sec delay with timestamps
`
18:21:34.034 TorSettings: loadFromPrefs() TorSettings.jsm:516:2118:21:34.038 TorConnect: Init TorConnect.jsm:238:2118:21:34.145 TorSettings: observed profile-after-change TorSettings.jsm:321:2118:21:34.145 TorConnect: observed profile-after-change TorConnect.jsm:245:2118:21:34.145 TorConnect: observing topic 'TorBootstrapStatus' TorConnect.jsm:257:3318:21:34.145 TorConnect: observing topic 'TorBootstrapError' TorConnect.jsm:257:3318:21:34.145 TorConnect: observing topic 'TorProcessExited' TorConnect.jsm:257:3318:21:34.145 TorConnect: observing topic 'TorLogHasWarnOrErr' TorConnect.jsm:257:3318:21:34.145 TorConnect: observing topic 'torsettings:ready' TorConnect.jsm:257:3318:21:34.155 [12-18 18:21:34] Torbutton NOTE: Initializing security-prefs.js18:21:34.156 [12-18 18:21:34] Torbutton NOTE: security-prefs.js initialization complete18:21:34.170 Unexpected event profile-after-change URLQueryStrippingListService.jsm:22418:21:34.338 Content Security Policy: Couldn’t parse invalid host 'wasm-eval'18:21:34.374 Bootstrapped manifest not allowed to use 'resource' directive. chrome.manifest:218:21:34.483 TorConnect: will load after bootstrap => [about:tor] TorConnect.jsm:493:2118:21:34.620 Could not load engine blockchair-onion@search.mozilla.org: Error: Extension is invalid SearchService.jsm:609:1718:21:34.620 1639851694620 addons.webextension.<unknown> ERROR Loading extension 'null': Reading manifest: Error processing chrome_settings_overrides.search_provider.search_form: String "http://blkchairbknpn73cfjhevhla7rkp4ed5gg2knctvv7it4lioy22defid.onion/search/?q={searchTerms}" must match /^(https:\/\/|http:\/\/(localhost|127\.0\.0\.1|\[::1\])(:\d*)?(\/|$)).*$/ Log.jsm:72318:21:34.667 Error: Can't find profile directory. XULStore.jsm:66:1518:21:34.954 Unchecked lastError value: Error: Could not establish connection. Receiving end does not exist. store.js:13518:21:35.202 [12-18 18:21:35] TorLauncher NOTE: failed to open authenticated connection: [scrubbed]18:21:36.265 [12-18 18:21:36] TorLauncher NOTE: failed to open authenticated connection: [scrubbed]18:21:36.639 NetworkError when attempting to fetch resource. RemoteSettingsClient.jsm:413:1418:21:36.816 NetworkError when attempting to fetch resource. IgnoreLists.jsm:90:1018:21:37.380 [12-18 18:21:37] TorLauncher NOTE: failed to open authenticated connection: [scrubbed]18:21:37.647 NetworkError when attempting to fetch resource. RemoteSettingsClient.jsm:413:1418:21:38.584 [12-18 18:21:38] TorLauncher NOTE: failed to open authenticated connection: [scrubbed]18:21:39.668 NetworkError when attempting to fetch resource. RemoteSettingsClient.jsm:413:1418:21:39.820 TorSettings: observed TorProcessIsReady TorSettings.jsm:321:2118:21:39.820 TorSettings: applySettings() TorSettings.jsm:651:2118:21:39.821 [12-18 18:21:39] TorLauncher NOTE: control connection is in use 218:21:39.822 TorConnect: observed TorBootstrapStatus TorConnect.jsm:245:2118:21:39.822 TorConnect: observed TorBootstrapStatus topic while in state TorConnectState.Initial TorConnect.jsm:284:2918:21:39.825 [12-18 18:21:39] Torbutton WARN: Local Tor check: unexpected GETINFO response: 250 OK18:21:40.096 TorConnect: observed torsettings:ready TorConnect.jsm:245:2118:21:40.097 TorConnect: beginConfigure() TorConnect.jsm:382:2118:21:40.097 TorConnect: transitioning state from Initial to Configuring TorConnect.jsm:224:2118:21:40.101 Tor NOTICE: DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.18:21:41.673 NetworkError when attempting to fetch resource. RemoteSettingsClient.jsm:413:1418:21:41.987 Key event not available on GTK2: key=“u” modifiers=“accel shift” id=“torbutton-new-identity-key” browser.xhtml18:21:41.987 Key event not available on some keyboard layouts: key=“i” modifiers=“accel,alt,shift” id=“key_browserToolbox” browser.xhtml)18:21:43.056 TypeError: window.RFPHelper is undefined64 RFPHelperParent.jsm:29:7
Tested around ~12 times each on an M1 running MacOS 12.0 & an Intel running MacOS 11.6. Didn't experience any issues save for the occasional ~0.5sec delay for the torconnect buttons to appear :)
@richard Let's follow-up on how to treat that delay in a separate ticket, yep?