GitLab

… otherwise it appears as "Tor Browser" in the taskbar.

I did not manage to prevent the omnibar from allowing search
so let's simply delete the search plugins, which is the same,
from an end-user perspective, as before: we hid the search bar
via userChrome.css.

I'm not removing this one-liner in userChrome.css though, just in case it's
re-enabled by default at some point via Tor Browser prefs or something.

AppArmor: give the Tor Browser "Web Content" process access to the system-wide webext directory (refs: #15717)

… otherwise uBlock cannot be loaded once we confine these processes under their
own AppArmor profile.

Confine Firefox 60 "Web Content" processes under the torbrowser_plugin_container AppArmor profile (refs: #15716)

It causes this error:

  ERROR: ld.so: object 'libmozsandbox.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.

… presumably because LD_LIBRARY_PATH is not set due to the "P" profile
transition flag.

These strings are now managed in po/*.po + Transifex.

This does not address the main problem (the name of the app in the taskbar)
but it's a start.

For some reason, it's ignored when we set it via
/usr/share/tails/tor-browser-prefs.js.

This probably won't be enough to fix #15706 ("Tor Browser 8 always prompts wrt.
asking webpages in English") until
https://trac.torproject.org/projects/tor/ticket/26409 is fixed.
But once Torbutton is fixed, then this should avoid Firefox prompting
the user.

It now works just fine with Firefox ESR60.

Cherry-picked from
https://github.com/micahflee/torbrowser-launcher/commit/ad95bbda69045f3c9ace241939ee9e1fccc16ac8

This code resets browser.uiCustomization.state, intl.locale.matchOS
and other stuff, which can be greatly confusing when working
specifically in this area of our Tor Browser customization.

pref() is not honored in prefs.js.

The Tor check done by Torbutton now works fine, no need to disable it anymore.

Shipping them in user.js has a few downsides:

 - They override whatever is in prefs.js so basically prefs in user.js are
   locked:  any modification done in about:config will be reverted next time Tor
   Browser starts, which can be a PITA when developing Tails.

 - In about:config, all these prefs are listed as modified by the user,
   which feels wrong.

 - It makes it harder for derivatives to implement things properly.

Display the Stop/Reload button in Tor Browser: our test suite currently depends on it (refs: #15023)

I could not find another reliable way to tell whether a page has loaded. I've
added a note on #11592 to revert this commit and find a better way, whenever we
work on this (fragile) part of our test suite.

As explained on https://github.com/gorhill/uBlock/releases/tag/1.16.6,
Firefox opens the sidebar by default whenever a webext that provides
one is installed, which is the case on first Tor Browser launch.

So let's do like upstream does in their released versions (the Debian build is
seen as a development one) and disable the logger sidebar.

This used to be needed to display all toolbar icons on first launch
but it does not work anymore, quite the opposite.

Besides, the problem this workaround'ed now affects Tor Browser
upstream so there's a chance it finally gets fixed:
https://trac.torproject.org/projects/tor/ticket/23359

I can't find where this would still be used.

As the comment says, they're handled in some other way already,
and we're not shipping these plugins so forcibly disabling them
does not buy us anything. Let's simplify things and get closer
to pristine Tor Browser.

I don't see why we need to diverge here.

There's been no Torbutton code that uses them for 2 years.

extensions.torbutton.banned_ports was deprecated 2 years ago.

I can't manage to have them be taken into account. Presumably
this would be doable by adding them to omni.ja but let's not bother:
I see little downside to simplify things here.

… otherwise uBlock cannot be loaded.

Otherwise it fails to render anything and its window is filled with black.

https://bugzilla.mozilla.org/show_bug.cgi?id=1450169

This area has become a recurring PITA across major Firefox upgrades,
needing more and more hacks every time. Now it's broken again for ESR60.
Let's drop the ball: if we really need something special, we can talk
to the Tor Browser team..

preferences/0000locale.js is apparently ignored.