- 10 Oct, 2019 5 commits
-
-
Mitchell Hentges authored
-
Sawyer Blatz authored
-
Mugurell authored
Could have implemented this check (if menu is showing) inside the show() method of BrowserMenu but this would mean the client (us) would go to the process of building a new menu and then trying to have it displayed only for this to be ignored by BrowserMenu in a somewhat opaque way. Having this check done as soon as possible offers us full control and avoids the unnecessary steps for building an already shown menu.
-
Grisha Kruglov authored
-
Sawyer Blatz authored
-
- 09 Oct, 2019 8 commits
-
-
Jeff Boek authored
-
Christian Sadilek authored
-
Emily Kager authored
-
Tiger Oakes authored
-
Ahmed I. Khalil authored
-
Michael Droettboom authored
-
Mozilla L10n Automation Bot authored
-
Roger Yang authored
-
- 08 Oct, 2019 17 commits
-
-
Tiger Oakes authored
-
Sawyer Blatz authored
-
Tiger Oakes authored
-
Severin Rudie authored
-
Severin Rudie authored
-
Severin Rudie authored
Updating themes recreates the activity, so if we aren't persisting 'usePrivateMode', we need to pass it to the new instance
-
Severin Rudie authored
-
Severin Rudie authored
As an added bonus, this makes the temporal coupling between `setPrivateModeIfNecessary` and `setupThemeAndBrowsingMode` explicit. They previously would have broken if called in reverse order, now it will fail to compile.
-
Severin Rudie authored
This didn't function when 'open links in a private tab' was set. Rather than adding another sketchy fix for the edge case, following commits will change `usePrivateMode` to be maintained in memory, instead of in Settings.
-
Mitchell Hentges authored
-
Johan Lorenzo authored
It was fixed in [1], but I regressed it when I resolved conflicts in [2] [1] https://github.com/mozilla-mobile/fenix/commit/9729fd494e524cea5f1ec979c7ae8d40dae4e596\#diff-3a2aaafc93fc8bb53e2029001aa236aeL98 [2] https://github.com/mozilla-mobile/fenix/commit/060e915d2bcb913e1e837289b24ff4895455b1cf\#diff-3a2aaafc93fc8bb53e2029001aa236aeR95
-
Johan Lorenzo authored
-
Aaron Train authored
-
Sawyer Blatz authored
-
Sawyer Blatz authored
-
Sawyer Blatz authored
-
Mihai Adrian authored
-
- 07 Oct, 2019 10 commits
-
-
Grisha Kruglov authored
-
Grisha Kruglov authored
This patch enabled support for an auto-publication workflow for android-components. It automates a common pattern seen in local development: Old way: - after every change in a-c, publish it locally with a unique version (bumping it manually) - manually modify Fenix to consume a custom version of a-c from a mavenLocal repository New way: - set a flag in fenix's local.properties to enable auto-publication - run Fenix builds after making changes to a-c. Changes in a-c will be automatically picked up. Note that no changes are necessary to any Fenix files other than a single flag in local.properties. Manually bumping android-components version is also not necessary.
-
Vipul Asri authored
-
Tiger Oakes authored
-
sv-ohorvath authored
Added a comment to the clear all bookmarks method
-
Michael Droettboom authored
-
Denys M authored
-
Denys M authored
-
Madalin Valceleanu authored
-
ekager authored
-