1. 19 Aug, 2020 1 commit
  2. 14 Aug, 2020 1 commit
  3. 29 May, 2020 1 commit
  4. 11 Jul, 2019 2 commits
  5. 29 May, 2019 1 commit
  6. 18 Aug, 2018 1 commit
  7. 06 Jul, 2018 1 commit
    • intrigeri's avatar
      Make Tor Browser less memory-hungry on systems with less than 3 GiB of RAM (refs: #15716). · 37e14889
      intrigeri authored
      With 2 GiB of RAM, the default settings (4 content child processes) make Tor
      Browser eat way too much memory: Tor Browser starts breaking after some browsing
      and our check for upgrades may fail. With 3 GiB of RAM and the default settings,
      once I open a bunch of tabs, start LibreOffice, Thunderbird, Files and KeePassX,
      then the system still works and Tor Browser is still snappy.
      37e14889
  8. 03 Jul, 2018 3 commits
  9. 01 Jul, 2018 1 commit
  10. 16 Mar, 2018 1 commit
  11. 18 Jan, 2018 1 commit
  12. 30 Sep, 2017 1 commit
    • intrigeri's avatar
      Force Tor Browser to enable accessibility support even if no a11y feature is... · a3346a75
      intrigeri authored
      Force Tor Browser to enable accessibility support even if no a11y feature is enabled in GNOME yet (refs: #14752, #9260).
      
      My understanding of the code in accessible/atk/Platform.cpp is: if this envvar
      is not set, Firefox will check via D-Bus at startup if accessibility is enabled
      in the Desktop, and if it's not it'll permanently disable accessibility,
      which breaks use cases like starting the screen keyboard or screen reader
      *after* Tor Browser.
      a3346a75
  13. 22 Sep, 2017 1 commit
  14. 21 Sep, 2017 1 commit
  15. 04 Jun, 2017 1 commit
    • anonym's avatar
      Tor Browser: kill the branding@amnesia.boum.org add-on. · bbee5530
      anonym authored
      This old school Firefox add-on is not compatible with e10s, so we move
      its functionality into our Tor Browser wrapper instead of porting to a
      WebExtension -- that would be more work, and we'd still have to do
      ugly stuff to work around mandatory signing.
      
      Refs: #12569
      
                                           _ " _
         _ " _                            (_\|/_)
        (_\|/_)   _ " _           _ " _    (/|\)
         (/|\)   (_\|/_) " _     (_\|/_)
                  (/|\)_\|/_)     (/|\)
                       (/|\)
      
      And yay, I found a use case for this kind of Enterprise feature that's
      not about enslaving corporate computers, but for freedom, love and all
      that good stuff! Namaste!
      
             ,,,                      ,,,
            {{{}}    ,,,             {{{}}    ,,,
         ,,, ~Y~    {{{}},,,      ,,, ~Y~    {{{}},,,
        {{}}} |/,,,  ~Y~{{}}}    {{}}} |/,,,  ~Y~{{}}}
         ~Y~ \|{{}}}/\|/ ~Y~  ,,, ~Y~ \|{{}}}/\|/ ~Y~  ,,,
         \|/ \|/~Y~  \|,,,|/ {{}}}\|/ \|/~Y~  \|,,,|/ {{}}}
         \|/ \|/\|/  \{{{}}/  ~Y~ \|/ \|/\|/  \{{{}}/  ~Y~
         \|/\\|/\|/ \\|~Y~//  \|/ \|/\\|/\|/ \\|~Y~//  \|/
         \|//\|/\|/,\\|/|/|// \|/ \|//\|/\|/,\\|/|/|// \|/
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      bbee5530
  16. 24 May, 2016 1 commit
  17. 11 Feb, 2016 1 commit
    • anonym's avatar
      Avoid set -u issue when testing if variable is set or not. · 364a3c8d
      anonym authored
      Whenever there's a risk that we will reference a shell variable in a
      script run with `set -u` (including libraries that we sources from
      such scripts) we must reference the variable in a way so it gets a
      default value, i.e. `${VAR:-}` to give it the empty string as the
      default (which is what generally makes sense).
      
      In particular, it's quite clear that in all cases where we do
      something like `[ -n "${VAR}" ]` or `[ -z "${VAR}" ]`, where an
      expected value is the empty string, which could mean that the variable
      is not initialized, we should give such a default (as the empty
      string).
      364a3c8d
  18. 10 Feb, 2016 1 commit
    • anonym's avatar
      Do the fontconfig dance with all browsers. · a8021ec0
      anonym authored
      I.e. also the Unsafe and I2P Browser's. The main reason is so we do
      not need different images for these and the Tor browser in the
      automated test suite. One may argue, though, that for the Unsafe
      Browser this list of fonts would be fingerprintable, but I would be
      surprised if it already isn't so due to the Tor Browser Firefox
      patches.
      a8021ec0
  19. 09 Feb, 2016 2 commits
  20. 06 May, 2015 1 commit
  21. 10 Feb, 2015 1 commit
    • Tails developers's avatar
      Run Tor Launcher in an unconfined Firefox. · 8adcfc21
      Tails developers authored
      Running Tor Launcher with the same AppArmor profile as Tor Browser would force
      us to open that profile too broadly. E.g. it requires the ability to run
      dbus-daemon, to give an idea.
      
      Given:
      
       * Tor Launcher runs as a dedicated user
       * Tor Launcher runs very early, at a time when the user likely isn't doing
         anything sensitive to X keystrokes sniffing etc., and closes immediately
         after Tor is ready
       * Tor Launcher offers a very limited set of functionality
      
      => it seems safe enough to run it unconfined, at least for now.
      8adcfc21
  22. 14 Jan, 2015 2 commits
    • Tails developers's avatar
      Use quoting more consistently. · e1bca43d
      Tails developers authored
      e1bca43d
    • Tails developers's avatar
      Make guess_best_tor_browser_locale() print the exact guessed locale. (Will-fix: #8693) · 67c4a51a
      Tails developers authored
      The rationale is easiest explained with an example: let
      LANG="pt_BR.UTF-8". Tor Browser doesn't have a "pt-BR" or even a "pt"
      langpack, but it does have a "pt-PT" package, which we want to
      use. Firefox is smart enough that it would pick the "pt-PT" package if
      we set the useragent to just "pt", which is what we did before.
      
      However, we also want to modify the langpack we're gonna use (to
      change the browser name) and we'll use the guessed locale for
      that. Since there's no "pt" package, the previous behaviour will fail,
      but it works fine if guess_best_tor_browser_locale() prints the exact
      locale for some langpack it thinks we should use, so let's do that.
      67c4a51a
  23. 14 Oct, 2014 1 commit
    • Tails developers's avatar
      Add localization helper functions for XUL applications. · 39772eda
      Tails developers authored
      That is for the various browsers and Tor Launcher. This will make it
      possible to drop the browser localization code from Tails Greeter's
      PostLogin script, where that really doesn't belong.
      
      Also, this new code is an improvement in that it will pick a "similar"
      locale if the specific one we look for isn't available. E.g. with
      pt-BR we will get pt, and the Firefox is smart enough to use the pt-PT
      langpack.
      39772eda
  24. 10 Oct, 2014 2 commits
    • Tails developers's avatar
      Drop useless "Browser" sub-directory in the TBB installation. · 63e3deea
      Tails developers authored
      It was a relic of the TBB 3.x times when the profile was located in
      the parent directory of the TBB browser files.
      
      Also patch Tails Greeter with the updated path. That patch should
      be dropped once it's been upstreamed into Tails Greeter.
      63e3deea
    • Tails developers's avatar
      Move TBB's global extensions dir. · a6c9aab6
      Tails developers authored
      The new place corresponds better to where Debian puts the Iceweasel
      extensions. Also, it will allow us to drop the useless "Browser"
      sub-dir in TBB_INSTALL without having potential collisions (e.g. if
      there was a "Browser/extensions").
      a6c9aab6
  25. 02 Oct, 2014 1 commit
  26. 24 Sep, 2014 1 commit