wrong default pref values in Tor Browser 8.0

The default values for some preferences are wrong in Tor Browser 8.0. For example, browser.dom.window.dump.enabled has a default value of true.

Maybe an issue similar to #27472 (moved) is affecting our desktop builds as well? See: https://dxr.mozilla.org/mozilla-esr60/source/modules/libpref/init/all.js#1090 where MOZILLA_OFFICIAL is used to choose some pref values.

added TorBrowserTeam201809R component::applications/tor browser ff60-esr owner::tbb-team priority::medium resolution::fixed severity::normal status::closed tbb-8.0-issues tbb-8.0.1-can type::defect labels

Trac:
Cc: ff60-esr, tbb-8.0-issues, tbb-8.0.1-can to N/A
Keywords: N/A deleted, ff60-esr, tbb-8.0-issues, tbb-8.0.1-can added

Replying to mcs:

The default values for some preferences are wrong in Tor Browser 8.0. For example, browser.dom.window.dump.enabled has a default value of true.

Maybe an issue similar to #27472 (moved) is affecting our desktop builds as well? See: https://dxr.mozilla.org/mozilla-esr60/source/modules/libpref/init/all.js#1090 where MOZILLA_OFFICIAL is used to choose some pref values. It's easily detectable by checking browser.safebrowsing.id which is set to navclient-auto-ffox for MOZILLA_OFFICIAL and Firefox otherwise (https://dxr.mozilla.org/mozilla-esr60/rev/b7dd3969261896020d7a9449d22f350a97e3517a/modules/libpref/init/all.js#5555).

Trac:
Username: reportUrl

Do we want that for 8.0.1? I am a bit wary to break things while switching to MOZILLA_OFFICIAL. What we should do at any rate is looking at the differences MOZILLA_OFFICIAL is causing and check whether the current status of Tor Browser 8 (i.e. not setting it) is problematic. If not, then we could give it a round of testing in 8.5a2 maybe? If we think we are good got 8.0.1, though, I am happy to take it for that point release.

Replying to gk:

Do we want that for 8.0.1? I am a bit wary to break things while switching to MOZILLA_OFFICIAL. What we should do at any rate is looking at the differences MOZILLA_OFFICIAL is causing and check whether the current status of Tor Browser 8 (i.e. not setting it) is problematic. If not, then we could give it a round of testing in 8.5a2 maybe? If we think we are good got 8.0.1, though, I am happy to take it for that point release.

Whether to take this for 8.0.1 is a difficult decision. Looking at the following, I am more concerned about the lack of MOZILLA_OFFICIAL than what will happen if we enable it: https://dxr.mozilla.org/mozilla-esr60/search?q=MOZILLA_OFFICIAL

For example, browser/base/content/browser-development-helpers.js is loaded, which adds a surprising "restart the browser now" shortcut key of Ctrl+Alt+R (Cmd+Alt+R)on macOS).

On the other hand, we have probably made all ESR60-based Tor Browser builds so far without it, so there may be some unexpected problems :(

Maybe that argues for trying it in 8.5a2.

Replying to mcs:

Replying to gk:

Do we want that for 8.0.1? I am a bit wary to break things while switching to MOZILLA_OFFICIAL. What we should do at any rate is looking at the differences MOZILLA_OFFICIAL is causing and check whether the current status of Tor Browser 8 (i.e. not setting it) is problematic. If not, then we could give it a round of testing in 8.5a2 maybe? If we think we are good got 8.0.1, though, I am happy to take it for that point release.

Whether to take this for 8.0.1 is a difficult decision. Looking at the following, I am more concerned about the lack of MOZILLA_OFFICIAL than what will happen if we enable it: https://dxr.mozilla.org/mozilla-esr60/search?q=MOZILLA_OFFICIAL

For example, browser/base/content/browser-development-helpers.js is loaded, which adds a surprising "restart the browser now" shortcut key of Ctrl+Alt+R (Cmd+Alt+R)on macOS).

Yes, but that should be a safe thing (even if unexpected), right?

On the other hand, we have probably made all ESR60-based Tor Browser builds so far without it, so there may be some unexpected problems :(

Maybe that argues for trying it in 8.5a2.

If you feel there is nothing that is potentially harmful then I'd take the safe approach and ship 8.5a2 with it first.

Here is a patch to use for 8.5a2: https://gitweb.torproject.org/user/brade/tor-browser.git/commit/?h=bug27623-01&id=e8d4909fcd059614106222a858d8839b58fee00f

Trac:
Keywords: N/A deleted, TorBrowserTeam201809R added
Status: new to needs_review

Enabled Remote Debugging / Backdoor don't bother you?

Trac:
Username: fuckingtrac

Replying to mcs:

Here is a patch to use for 8.5a2: https://gitweb.torproject.org/user/brade/tor-browser.git/commit/?h=bug27623-01&id=e8d4909fcd059614106222a858d8839b58fee00f

That looks good to me. However, we do not sync the mozconfig files in tor-browser with those we actually use for building the browser part in tor-browser-build yet (see: #23656 (moved)). Thus, could you add the relevant tor-browser-build changes as well?

Trac:
Status: needs_review to needs_revision
Keywords: TorBrowserTeam201809R deleted, TorBrowserTeam201809 added

Replying to gk:

That looks good to me. However, we do not sync the mozconfig files in tor-browser with those we actually use for building the browser part in tor-browser-build yet (see: #23656 (moved)). Thus, could you add the relevant tor-browser-build changes as well?

Sorry about that; for some reason I thought we had fixed that problem. We should ;) Here is a tor-browser-build patch: https://gitweb.torproject.org/user/brade/tor-browser-build.git/commit/?h=bug27623-01&id=f49b8306354f68dcaf8efeec8a4bd8b5a8908e6b

Trac:
Status: needs_revision to needs_review
Keywords: TorBrowserTeam201809 deleted, TorBrowserTeam201809R added

Replying to mcs:

Replying to gk:

That looks good to me. However, we do not sync the mozconfig files in tor-browser with those we actually use for building the browser part in tor-browser-build yet (see: #23656 (moved)). Thus, could you add the relevant tor-browser-build changes as well?

Sorry about that; for some reason I thought we had fixed that problem. We should ;)

Indeed! Patches welcome. ;)

Here is a tor-browser-build patch: https://gitweb.torproject.org/user/brade/tor-browser-build.git/commit/?h=bug27623-01&id=f49b8306354f68dcaf8efeec8a4bd8b5a8908e6b

Looks good to me. I merged that one to tor-browser-build's master (commit f49b8306354f68dcaf8efeec8a4bd8b5a8908e6b).

And cherry-picked the tor-browser patch to tor-browser-60.2.0esr-8.5-1 (commit cfcf68c7ef27d33f072a405ef7e99815f5e34c1d).

Trac:
Resolution: N/A to fixed
Keywords: N/A deleted, tbb-backport added
Status: needs_review to closed

Marked #28133 (moved) as a duplicate.

Trac:
Cc: N/A to ev9F8itL

Note: for backporting we need #28039 (moved) fixed, too.

Resolved #28385 (moved) as a duplicate.

Trac:
Cc: ev9F8itL to ev9F8itL, califuture

We'd need the fix for #28618 (moved) and thus #26148 (moved), too, for Windows. I think that's beyond my comfort zone for backporting. We could backport a separate patch for macOS and Linux. Or just wait for 8.5 which is close. I think we should do the latter.

Trac:
Keywords: tbb-backport deleted, N/A added

closed

mentioned in issue #27865 (moved)

mentioned in issue #28039 (moved)

mentioned in issue #28133 (moved)

mentioned in issue #28222 (moved)

mentioned in issue #28385 (moved)

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