Tor Browser log is not shown anymore in terminal since Tor Browser 8.5a2

Starting with Tor Browser 8.5a2 no log is shown anymore in the terminal on Linux.

STR:

1. Start Tor Browser with ./start-tor-browser.desktop --debug
2. Open about:config and set extensions.torbutton.loglevel to 3 and extensions.torbutton.logmethod to 0
3. Go to torproject.org

Expected: See circuit building related output in terminal Actual: No log messages show up.

added GeorgKoppen201810 TorBrowserTeam201811R component::applications/tor browser owner::tbb-team priority::medium resolution::fixed severity::normal status::closed tbb-regression type::defect labels

I used a 8.5a1 and replaced the Torbutton and tor version with the ones we ship in 8.5a2, nothing changes.

Trac:
Keywords: N/A deleted, GeorgKoppen201810 added

The problem is the fix for #27623 (moved). More specifically, browser.dom.window.dump.enabled is now the preference that is relevant here: while logging was still possible in Tor Browser 7.x with it set to false this is not the case anymore in Firefox based on ESR 60 it seems. And MOZILLA_OFFICIAL toggles it.

I wonder whether we should follow Mozilla here and add an extra step to get logging going. But on the other hand if I start Tor Browser with --log I expect that it does what it promises and logs. Not doing so, or needing to do yet another thing to get that going sounds like a bug.

So, should we enable browser.dom.window.dump.enabled for macOS and Linux then?

Trac:
Cc: N/A to mcs, brade

Replying to gk:

So, should we enable browser.dom.window.dump.enabled for macOS and Linux then?

I say yes, or just enable it for all platforms, e.g., by setting browser.dom.window.dump.enabled to true in 000-tor-browser.js.

For reference: "dump() in JS Components should obey browser.dom.window.dump.enabled" https://bugzilla.mozilla.org/show_bug.cgi?id=379797

"Enable dump() by default in local builds" https://bugzilla.mozilla.org/show_bug.cgi?id=1395711

I think I have a better plan: We enable browser.dom.window.dump.enabled in case one of Torbutton's/Tor Launcher's logmethod prefs gets set to 0 and disable it if both of them are non-0 (which is Tor Browser's default state).

Okay, this took me longer than planned. :/ bug_28039_v3 in the torbutton (https://gitweb.torproject.org/user/gk/torbutton.git/commit/?h=bug_28039_v3&id=75e31589b9647b5c67374b28f0cb15929e32d52a) and bug_28039_v2 in the tor-launcher (https://gitweb.torproject.org/user/gk/tor-launcher.git/commit/?h=bug_28039_v2&id=8a7059a334ba582f5440440b3792cbd7e9b0d4df) repo have proposed fixes.

Trac:
Keywords: TorBrowserTeam201810 deleted, TorBrowserTeam201810R added
Status: new to needs_review

Moving reviews to November.

Trac:
Keywords: TorBrowserTeam201810R deleted, TorBrowserTeam201811R added

r=brade, r=mcs One tiny nit: the second backtick character in the Tor Launcher commit message is slightly misplaced, i.e., the first line should be: Without setting browser.dom.window.dump.enabled explicitly to true (transpose the ` and space after the pref name).

Thanks. I fixed the backtick issue and pushed both commits to their respective master branches (commit 80749f18beb93f94cb6be9a5e2c17438ff133ab8 for tor-launcher and commit 923fd8500a16b0a343450621a62ea10175c38b3d for `torbutton).

Trac:
Status: needs_review to closed
Resolution: N/A to fixed

closed

mentioned in issue #28167 (moved)

moved to tpo/applications/tor-browser#28039 (closed)