GitLab

It's actually the same dialog for all GTK3 apps and e.g. Tor Browser 8
can now reuse it.

Test suite: take into account that the Reload button now looks different in the Unsafe Browser than in Tor Browser (refs: #15023)

It has the red theme applied.

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.

There's no "document frame" anymore, now it's a "frame".
And we don't need the special case about "Getting started…"
since we don't point there anymore.

The basebox currently used by most our branches is now 4 months old,
so every build on Jenkins starts by deleting it… and then recreates
it from scratch. Six months is more in line with the delay between
our major releases these days.

This reverts commit fc1bba10.

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