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
Unrelated to RTL changes but these names are awful and gotta go!
MozReview-Commit-ID: Kud6tgfEGkk
--HG--
rename : mobile/android/app/src/main/res/layout/activity_stream_card_history_item.xml => mobile/android/app/src/main/res/layout/activity_stream_webpage_item_row.xml
extra : rebase_source : 9a2b980a8f00ddb2cb28a24ab85d684df04b05b7
Unrelated to RTL changes but these names are awful and gotta go!
MozReview-Commit-ID: Kud6tgfEGkk
--HG--
rename : mobile/android/app/src/main/res/layout/activity_stream_card_history_item.xml => mobile/android/app/src/main/res/layout/activity_stream_webpage_item_row.xml
extra : rebase_source : 9369fd07eb959caf800cad58b37e543b83402b08
I tested this by replacing the placeholder top story URLs with [1], clicking on
the links, and verifying clicks from top stories included the referrer but
clicks from highlights and top sites did not.
[1]: https://www.whatismybrowser.com/detect/what-http-headers-is-my-browser-sending
MozReview-Commit-ID: CcOxkvNgOHY
--HG--
extra : rebase_source : 68d17e59231fb5e7fc4232d4256b925e6e4fce7e
This will allow us to call Tabs.loadUrl with a referrer URI from the Pocket top
stories.
MozReview-Commit-ID: IGdoTo80SGG
--HG--
extra : rebase_source : 52c616720fb1735e593f02330d1dd02db45f501f
We might decide that there's an older dateAdded timestamp present for an incoming bookmark while processing it,
in which case we need to ensure that our changes will be uploaded.
MozReview-Commit-ID: BKLh4rYBiRu
--HG--
extra : rebase_source : 3f8ac41de99d7082cd9d7fc7254386d99d5431bd
As implemented, this means we might upload tombstones for never-synced
bookmarks. This _should_ be harmless.
MozReview-Commit-ID: DZx9yWDs1ie
--HG--
extra : rebase_source : d4abf10bded3f6ab39d13f0152cf981cd9fe4df7
Right now we have two Snackbar handlers in GeckoApp and
GeckoPreferences, respectively. This patch combines the two handlers
into one inside GeckoApplication, and lets us display Snackbars in other
Activities like custom tabs and PWA.
MozReview-Commit-ID: Iu6p2VNnVVC
--HG--
extra : rebase_source : 7fa018a3efd251c2e91aeea31e9ca85d872ebe59
Instead of initializing IntentHelper in GeckoApp, initialize it in
GeckoApplication, and make it available globally. This will let custom
tabs / PWA use IntentHelper-provided services.
MozReview-Commit-ID: Icedph6KG4u
--HG--
extra : rebase_source : 819c10edce4fc4f6a46e8cfba34a9fd4afa35e86
Use tint to provide two colors for page action icon in normal/private mode.
We would not tint icons that already have their own colors(for example: ic_readermode_on.png or casting_active.png)
or are came from 3-party addons.
MozReview-Commit-ID: 8uuMucKGLw5
--HG--
extra : rebase_source : 7d213e2b96fab8389b2b2c69e1fdb8ecfe569f20
extra : intermediate-source : ee7c5cecab194ae54317d77de05b2e2f84e1122e
extra : source : a97a2b9700a27e944691536adec6112451ff1f24
If all edges of a favicon are the same colour, we should use that
as the background colour too - that way the favicon no longer appears
distinct from the background. We still fall back to the dominant colour
in most cases, however this improves favicon appearance for some websites.
MozReview-Commit-ID: 6xkgXxHHla2
--HG--
extra : rebase_source : c33807fa2b972b5d4d4f44e8e321883b8880f480
If all edges of a favicon are the same colour, we should use that
as the background colour too - that way the favicon no longer appears
distinct from the background. We still fall back to the dominant colour
in most cases, however this improves favicon appearance for some websites.
MozReview-Commit-ID: 6xkgXxHHla2
--HG--
extra : rebase_source : c33807fa2b972b5d4d4f44e8e321883b8880f480
We use an extra mask for url bar to make url text more clear.
MozReview-Commit-ID: D4ngrRdAof6
--HG--
extra : rebase_source : 4654058e6d966a033c816c3b47140ac8f607d7ed
extra : source : 0608e38913d521899ecc3d907167984ef22816cd
