wrong default pref values in Tor Browser 8.0

[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 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.

[reportUrl]

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 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).

[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.

[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).

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.

[gk]

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.

[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

[fuckingtrac]

Enabled Remote Debugging / Backdoor don't bother you?

[gk]

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). Thus, could you add the relevant tor-browser-build changes as well?

[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). 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

[gk]

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). 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).

[gk]

Marked #28133 as a duplicate.

[gk]

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

[gk]

Resolved #28385 as a duplicate

[gk]

We'd need the fix for #28618 and thus #26148, 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.