1. 24 Mar, 2021 7 commits
    • Alex Catarineu's avatar
      Bug 26345: Hide tracking protection UI · 7f0450d9
      Alex Catarineu authored and Matthew Finkel's avatar Matthew Finkel committed
    • Richard Pospesel's avatar
      Bug 25658: Replace security slider with security level UI · 41d94592
      Richard Pospesel authored and Matthew Finkel's avatar Matthew Finkel committed
      This patch adds a new 'securitylevel' component to Tor Browser intended
      to replace the torbutton 'Security Slider'.
      This component adds a new Security Level toolbar button which visually
      indicates the current global security level via icon (as defined by the
      extensions.torbutton.security_slider pref), a drop-down hanger with a
      short description of the current security level, and a new section in
      the about:preferences#privacy page where users can change their current
      security level. In addition, the hanger and the preferences page will
      show a visual warning when the user has modified prefs associated with
      the security level and provide a one-click 'Restore Defaults' button to
      get the user back on recommended settings.
      Strings used by this patch are pulled from the torbutton extension, but
      en-US defaults are provided if there is an error loading from the
      extension. With this patch applied, the usual work-flow of "./mach build
      && ./mach run" work as expected, even if the torbutton extension is
    • Kathleen Brade's avatar
      Bug 21431: Clean-up system extensions shipped in Firefox · e60cd85b
      Kathleen Brade authored and Matthew Finkel's avatar Matthew Finkel committed
      Only ship the pdfjs extension.
    • Mike Perry's avatar
      Omnibox: Add DDG, Startpage, Disconnect, Youtube, Twitter; remove Amazon, eBay, bing · cad57f53
      Mike Perry authored and Matthew Finkel's avatar Matthew Finkel committed
      eBay and Amazon don't treat Tor users very well. Accounts often get locked and
      payments reversed.
      Bug 16322: Update DuckDuckGo search engine
      We are replacing the clearnet URL with an onion service one (thanks to a
      patch by a cypherpunk) and are removing the duplicated DDG search
      engine. Duplicating DDG happend due to bug 1061736 where Mozilla
      included DDG itself into Firefox. Interestingly, this caused breaking
      the DDG search if JavaScript is disabled as the Mozilla engine, which
      gets loaded earlier, does not use the html version of the search page.
      Moreover, the Mozilla engine tracked where the users were searching from
      by adding a respective parameter to the search query. We got rid of that
      feature as well.
      This fixes bug 20809: the DuckDuckGo team has changed its server-side
      code in a way that lets users with JavaScript enabled use the default
      landing page while those without JavaScript available get redirected
      directly to the non-JS page. We adapt the search engine URLs
      Also fixes bug 29798 by making sure we only specify the Google search
      engine we actually ship an .xml file for.
      Also regression tests.
    • Kathleen Brade's avatar
      Bug 16940: After update, load local change notes. · a811007a
      Kathleen Brade authored and Matthew Finkel's avatar Matthew Finkel committed
      Add an about:tbupdate page that displays the first section from
      TorBrowser/Docs/ChangeLog.txt and includes a link to the remote
      post-update page (typically our blog entry for the release).
      Always load about:tbupdate in a content process, but implement the
      code that reads the file system (changelog) in the chrome process
      for compatibility with future sandboxing efforts.
      Also fix bug 29440. Now about:tbupdate is styled as a fairly simple
      changelog page that is designed to be displayed via a link that is on
    • Kathleen Brade's avatar
      Bug 4234: Use the Firefox Update Process for Tor Browser. · 0368a1af
      Kathleen Brade authored and Matthew Finkel's avatar Matthew Finkel committed
      The following files are never updated:
      Mac OS: Store update metadata under TorBrowser/UpdateInfo.
      Removed the %OS_VERSION% component from the update URL (13047) and
        added support for minSupportedOSVersion, an attribute of the
        <update> element that may be used to trigger Firefox's
        "unsupported platform" behavior.
      Hide the "What's new" links (set app.releaseNotesURL value to about:blank).
      Windows: disable "runas" code path in updater (15201).
      Windows: avoid writing to the registry (16236).
      Also includes fixes for tickets 13047, 13301, 13356, 13594, 15406,
        16014, 16909, 24476, and 25909.
      Also fix Bug 26049: reduce the delay before the update prompt is displayed.
      Instead of Firefox's 2 days, we use 1 hour (after which time the update
      doorhanger will be displayed).
      Also fix bug 27221: purge the startup cache if the Tor Browser
      version changed (even if the Firefox version and build ID did
      not change), e.g., after a minor Tor Browser update.
      Also fix 32616: Disable GetSecureOutputDirectoryPath() functionality.
      Bug 26048: potentially confusing "restart to update" message
      Within the update doorhanger, remove the misleading message that mentions
      that windows will be restored after an update is applied, and replace the
      "Restart and Restore" button label with an existing
      "Restart to update Tor Browser" string.
      Bug 28885: notify users that update is downloading
      Add a "Downloading Tor Browser update" item which appears in the
      hamburger (app) menu while the update service is downloading a MAR
      file. Before this change, the browser did not indicate to the user
      that an update was in progress, which is especially confusing in
      Tor Browser because downloads often take some time. If the user
      clicks on the new menu item, the about dialog is opened to allow
      the user to see download progress.
      As part of this fix, the update service was changed to always show
      update-related messages in the hamburger menu, even if the update
      was started in the foreground via the about dialog or via the
      "Check for Tor Browser Update" toolbar menu item. This change is
      consistent with the Tor Browser goal of making sure users are
      informed about the update process.
      Removed #28885 parts of this patch which have been uplifted to Firefox.
    • Alex Catarineu's avatar
      Bug 10760: Integrate TorButton to TorBrowser core · 399f6a34
      Alex Catarineu authored and Matthew Finkel's avatar Matthew Finkel committed
      Because of the non-restartless nature of Torbutton, it required
      a two-stage installation process. On mobile, it was a problem,
      because it was not loading when the user opened the browser for
      the first time.
      Moving it to tor-browser and making it a system extension allows it
      to load when the user opens the browser for first time.
      Additionally, this patch also fixes Bug 27611.
      Bug 26321: New Circuit and New Identity menu items
      Bug 14392: Make about:tor behave like other initial pages.
      Bug 25013: Add torbutton as a tor-browser submodule
  2. 15 Mar, 2021 1 commit
  3. 11 Mar, 2021 1 commit
  4. 26 Feb, 2021 2 commits
  5. 09 Mar, 2021 1 commit
  6. 10 Mar, 2021 1 commit
  7. 08 Mar, 2021 1 commit
  8. 10 Mar, 2021 1 commit
  9. 01 Mar, 2021 1 commit
    • Anny Gakhokidze's avatar
      Bug 1692501 - Fix timing issues when reopening all closed windows, r=kashav, a=jcristau · ac02529c
      Anny Gakhokidze authored
      In bug 1589102, changes were made to how about:blank and about:srcdoc load,
      making them go via DocumentChannel and thus slightly increasing documents' load
      times.  This causes some timing issues in SessionStore code.
      When we click to "Reopen all (closed) Windows", undoCloseWindow() is called for
      each window that we have to restore. The following scenario can occur - we are
      restoring window 1, and undoCloseWindow() has already called restoreWindows,
      after receiving the window showing promise, and in the meantime
      undoCloseWindow() has been called for window 2, and there is now a promise in
      the WINDOW_SHOWING_PROMISES. But now restoreWindows() for window1 calls
      _openWindows(), where root.windows length is 0, but WINDOW_SHOWING_PROMISES is
      not empty (because of window 2's undoCloseWindow), and the resolve callback for
      _openWindows() gets called with wrong arg. To solve this, ensure that the
      promises returned from _openWindows() correspond to the windows opened
      within the body of the function.
      Differential Revision: https://phabricator.services.mozilla.com/D106304
  10. 03 Mar, 2021 3 commits
  11. 02 Mar, 2021 1 commit
    • Drew Willcoxon's avatar
      Bug 1692615 - Make sure Quick Suggest results are accessible. r=harry,Jamie, a=jcristau · 43ef43ed
      Drew Willcoxon authored
      This fixes the two a11y problems with quick suggest results:
      * When their help button is present, they aren't recognized as a listbox
        option. That has a couple of consequences: They aren't read as an "<index> of
        <size>" option, and they're read as an autocompleted URL instead of their
      * Their help button is read as its URL instead of its label. (The button has a
        URL that's loaded when you click it.)
      Fixing the second problem is easy, just give the help button an ID.
      The first problem is trickier. It's due to the fact that when the help button is
      present in the actual row, the "logical" row -- the part that's selectable and
      looks like the main part of the row -- is not the row itself but rather one of
      its children. So the rows container with `role=listbox` doesn't have the
      selectable part as a direct child. To fix that, I added `role=option` to the
      selectable part and `role=presentation` to the row itself.
      Aside from these fixes, another possibility is to include the row's help button
      as an option too, instead of as a button. I chose not to do that because it's
      really a button and not a row/result, and also we have precedent with tip
      results, which have similar buttons that we treat like this.
      Note that the help button is *not* read on hover, only when keyboard selected.
      That's a known bug we encountered in tips or interventions, but I can't find the
      Depends on D106559
      Differential Revision: https://phabricator.services.mozilla.com/D106712
  12. 01 Mar, 2021 1 commit
  13. 02 Mar, 2021 2 commits
  14. 01 Mar, 2021 1 commit
  15. 02 Mar, 2021 1 commit
  16. 25 Feb, 2021 4 commits
  17. 26 Feb, 2021 4 commits
  18. 25 Feb, 2021 5 commits
  19. 24 Feb, 2021 2 commits