We're not lazy-loading Task.jsm in Messaging.jsm right now (despite
declaring it through XPCOMUtils.defineLazyModuleGetter) because we
unnecessarily reference `Task` when Messaging.jsm is loading. This patch
makes us load Task.jsm only when `Task` is really needed.
MozReview-Commit-ID: 9rrnLQLaW4y
--HG--
extra : rebase_source : fab1379719a9fdf75ce45b1002d03300e5dbd9e8
Standalone GeckoView doesn't make use of MDNS AFAIK (i.e. MDNS is only
used by features like casting or FlyWeb), but it takes up startup time,
so we should disable it.
MozReview-Commit-ID: CseHUos5B9I
--HG--
extra : rebase_source : 2dc6af2a360da05cf3d6ba2aaae87a64dd67c480
Lazily load AndroidLog.jsm since we only need it for debug logging, and
logging is normally turned off in GeckoView code.
MozReview-Commit-ID: 5HNzYTwujMS
--HG--
extra : rebase_source : 5ef9bbe21ff1a53bc0e805f473154e1cf60d3b08
Add a GeckoViewStartup component to consolidate tasks performed during
GeckoView startup, such as adding lazy observers and event listeners.
This enables us to not load individual GeckoView modules such as
GeckoViewPermission and GeckoViewPrompt until they are actually needed.
MozReview-Commit-ID: IsaUGwBHKbs
--HG--
extra : rebase_source : c22e71eda6ad11230046de64dc54c882be2ed555
Move AsyncPrefs initialization to inside browser.js to only load it for
Fennec. Also, delay initialization until later in startup.
MozReview-Commit-ID: 7gLaXA5UJud
--HG--
extra : rebase_source : c721bbc6c9340f65161c415405dfba16e527b962
Currently, this only concerns setImageAs, where not running on the UI thread after a permissions prompt triggers a network-related strict mode violation and interestingly enough results in a crash (as opposed to a logcat complaint) on release builds.
There's also a permissions check in the UpdateService which runs on a (but not *the*) background thread, but since we don't prompt in that case there's no action necessary.
MozReview-Commit-ID: KKxW96AyDWH
--HG--
extra : rebase_source : db12529acc9b257930c37c2295f69a7b8e75232c
The permissions check itself is synchronous, but if we then decide to prompt the user to acquire the permission, we have to do so asynchronously and eventually continue execution on the UI thread as a result. Therefore we need to provide a counterpart of onUIThread() for operations that want their callback to stay off the UI thread in all situations.
MozReview-Commit-ID: AOCX1v69R1J
--HG--
extra : rebase_source : ed0bab9f3ae3198bf2af90eabc86fd5ddd95b3a0
Adjust icon position and increase text size of title field.
MozReview-Commit-ID: F0eb8m7dvHY
--HG--
extra : rebase_source : ee7f8464ac857bbdfb39eb96b7a9902c09e58066
The tint logic for menu icons on different devices is:
Normal mode:
1. Mobile & small tablet -> dark color(#272727)
2. Large tablet -> dark color(#272727)
Private mode:
1. Mobile & small tablet -> dark color(#272727)
2. Large tablet -> light color(#38383D)
MozReview-Commit-ID: 9cz53PieQHY
--HG--
extra : rebase_source : 780a3ae9701d30672153801c88ade56c081a64d1
When app is not runing, Gecko is not running. Thus we can't get Gecko pref.
We should skip Gecko pref check and show notifications when we recieve push messages and while app is not running.
Other checks (ie. Switchboard, Health Report...etc) remain the same.
MozReview-Commit-ID: H2X18VI0cnW
--HG--
extra : rebase_source : 28c4946ba8f4a9721735f93db728c28fa70d6b9d
Preprocess the generated bindings to support the new BuildFlag
annotation, so that we can compare bindings despite build flag changes.
The build system preprocessor is used because it's easy-to-use and
invoking the actual C++ preprocessor would require much more work.
However, as a result, we use a MOZ_PREPROCESSOR macro to make the build
system preprocessor not handle `#include` lines in the binding files.
MozReview-Commit-ID: 3Gweuwnb1V3
--HG--
extra : rebase_source : 3a1769e4b45bab3175b3609d08e53534380facce
Add a BuildFlag annotation, which when specified for classes, will wrap
generated code in `#ifdef` or `#ifndef` blocks. This functionality is
used for conditionally excluding generated code when NIghtly becomes
Beta, without the need to regenerate bindings.
MozReview-Commit-ID: L2NFM8CHKqF
--HG--
extra : rebase_source : 6ebc82d11fd1aa4aeb57a46262e678480d23de83
We show a message:
1) On first run
2) When there are no highlights
However, these are actually the same case (there are no highlights) so I wanted
to defer to that situation.
I felt it was easier to rm the WelcomePanel and rewrite it than it was to try
to morph it into an empty state for the highlights.
MozReview-Commit-ID: CrRbzA0NoRx
--HG--
extra : rebase_source : ed21103350ea13813062e214d3aec22805cfa7d7
We show a message:
1) On first run
2) When there are no highlights
However, these are actually the same case (there are no highlights) so I wanted
to defer to that situation.
I felt it was easier to rm the WelcomePanel and rewrite it than it was to try
to morph it into an empty state for the highlights.
MozReview-Commit-ID: CrRbzA0NoRx
--HG--
extra : rebase_source : da48e11003d8decb8216d1439a9ca475f56cbb7e
