1. 04 May, 2021 2 commits
    • Alex Catarineu's avatar
      Bug 10760: Integrate TorButton to TorBrowser core · a2581936
      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
      a2581936
    • Kathleen Brade's avatar
      Bug 28044: Integrate Tor Launcher into tor-browser · d187d0db
      Kathleen Brade authored and Matthew Finkel's avatar Matthew Finkel committed
      Build and package Tor Launcher as part of the browser (similar to
      how pdfjs is handled).
      
      If a Tor Launcher extension is present in the user's profile, it is
      removed.
      d187d0db
  2. 02 Mar, 2021 3 commits
  3. 10 Feb, 2021 1 commit
  4. 05 Feb, 2021 1 commit
  5. 04 Feb, 2021 1 commit
  6. 11 Dec, 2020 1 commit
  7. 10 Dec, 2020 1 commit
  8. 26 Nov, 2020 1 commit
  9. 18 Nov, 2020 1 commit
  10. 17 Nov, 2020 1 commit
  11. 19 Nov, 2020 1 commit
  12. 04 Nov, 2020 1 commit
    • Shane Caraveo's avatar
      Bug 1672314 handle invalid addon startup data properly during startup r=rpl · d31bd61d
      Shane Caraveo authored
      We scan for addon changes twice, once early in startup (usually with no scanning) and once after ui startup.  We hold on to the startup data, and during both scans we restore that data into the addon location instances.  The problem here is if we install a builtin in-between these scans.  The new data from the install would get overwitten by the old data.  In some cases this caused addons to disappear (e.g. old data has incorrect path).  Other issues covered here is that we would never remove addon data for builtins removed from the system, and we would additionally mark builtins as sideloads, which caused other side effects (particularly with search addons) where we would not load the addon, but fortunately the search service later re-installes them.
      
      Differential Revision: https://phabricator.services.mozilla.com/D95422
      d31bd61d
  13. 03 Nov, 2020 2 commits
    • Razvan Maries's avatar
      Backed out changeset 09a20cd2699f (bug 1672314) for perma failures on... · c8bc7a3e
      Razvan Maries authored
      Backed out changeset 09a20cd2699f (bug 1672314) for perma failures on browser_html_detail_view.js. CLOSED TREE
      c8bc7a3e
    • Shane Caraveo's avatar
      Bug 1672314 handle invalid addon startup data properly during startup r=rpl · 6a578427
      Shane Caraveo authored
      We scan for addon changes twice, once early in startup (usually with no scanning) and once after ui startup.  We hold on to the startup data, and during both scans we restore that data into the addon location instances.  The problem here is if we install a builtin in-between these scans.  The new data from the install would get overwitten by the old data.  In some cases this caused addons to disappear (e.g. old data has incorrect path).  Other issues covered here is that we would never remove addon data for builtins removed from the system, and we would additionally mark builtins as sideloads, which caused other side effects (particularly with search addons) where we would not load the addon, but fortunately the search service later re-installes them.
      
      Differential Revision: https://phabricator.services.mozilla.com/D95422
      6a578427
  14. 25 Sep, 2020 1 commit
  15. 11 Sep, 2020 1 commit
  16. 21 Sep, 2020 1 commit
  17. 15 Oct, 2020 1 commit
    • Rob Wu's avatar
      Bug 1601678 - Resolve shutdown deadlock in EnvironmentAddonBuilder r=mixedpuppy · dc4938fe
      Rob Wu authored
      TelemetryEnvironment.jsm's EnvironmentAddonBuilder has a shutdown
      blocker that depends on the addons database to have been loaded.
      There are two calls to asyncLoadDB() in XPIProvider.jsm that are
      supposed to activate the load. Neither of them work:
      
      - XPIProvider calls asyncLoadDB() during quitApplicationGranted.
        But "quit-application-granted" is not always triggered, as seen in:
        https://bugzilla.mozilla.org/show_bug.cgi?id=1601678#c12
      
      - XPIProvider.shutdown() calls asyncLoadDB().
        But shutdown() is only called when TelemetryEnvironment's blocker has
        been released. So this is never reached. More details in:
        https://bugzilla.mozilla.org/show_bug.cgi?id=1601678#c7
      
      To fix the deadlock, asyncLoadDB() is called from profile-before-change,
      which is the same phase as the blocker of EnvironmentAddonBuilder.
      
      The two existing calls to asyncLoadDB() mentioned above are obsolete and
      have been removed.
      
      ---
      
      After the removal of asyncLoadDB() from XPIProvider.shutdown(), the
      test_ext_persistent_events.js test started to fail. This is because the
      test sends the "sessionstore-windows-restored" notification, for which
      XPIProvider has a handler that calls asyncLoadDB(), without awaiting
      the result.
      Since XPIProvider.shutdown() doesn't await the DB load any more, it is
      possible for the DB to be unloaded while being used. This only happens
      in tests, because the construction with the TelemetryEnvironment ensures
      that the addons database has fully loaded before shutdown() is called.
      
      To resolve this test-only issue, AddonTestUtils.promiseShutdownManager()
      has been updated to explicitly wait for the pending _dbPromise if any.
      
      Differential Revision: https://phabricator.services.mozilla.com/D91388
      dc4938fe
  18. 20 Jul, 2020 2 commits
  19. 26 Jun, 2020 1 commit
  20. 08 Sep, 2020 2 commits
  21. 19 Jul, 2020 1 commit
  22. 17 Jul, 2020 1 commit
  23. 15 May, 2020 3 commits
  24. 11 May, 2020 2 commits
  25. 30 Apr, 2020 5 commits
  26. 29 Apr, 2020 2 commits