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.
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.
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.
It was fixed in [1], but I regressed it when I resolved conflicts in [2]
[1] 9729fd494e\#diff-3a2aaafc93fc8bb53e2029001aa236aeL98
[2] 060e915d2b\#diff-3a2aaafc93fc8bb53e2029001aa236aeR95
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.
Johan Lorenzo
Jeff Boek
Mihai Adrian
Mozilla L10n Automation Bot
Sawyer Blatz
Mugurell
Grisha Kruglov
Christian Sadilek
Emily Kager
Tiger Oakes
Ahmed I. Khalil
Michael Droettboom
Roger Yang
Severin Rudie
Mitchell Hentges
Aaron Train
Vipul Asri
sv-ohorvath
Denys M
Madalin Valceleanu
ekager
Prat T