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.
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.
* Do not launch in Private Mode
When the app launches do not launch in Private Mode in order to prevent usage leaks to other users of the device.
* Issue #4780: add comments to use private mode
* For #4780: write tests for clear private mode on create app
* For #4780: clear private mode when privacy notification is removed