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
Fix the following lint errors/warnings,
* Using inlined constants on older versions
Add version check for usages of Intent.EXTRA_ALLOW_MULTIPLE and
Intent.EXTRA_MIME_TYPES.
* Calling new methods on older versions
Change usages of AlertDialog.Builder#setOnDismissListener to
Dialog#setOnDismissListener instead.
* Missing recycle() calls
Add missing TypedArray#recycle call
MozReview-Commit-ID: EwZFDKqoCjL
Add tests for synthesizing keys, including test for dummy keys and test
for wrong metastate for synthesized non-English keys (i.e. bug 1387889).
MozReview-Commit-ID: SvddU2BHle
Comment from bugzilla on this ugly hack:
While processing bookmarks, we sometimes need to mark them for re-upload as we're inserting new ones or updating existing ones. For example, we might set or update a dateAdded field.
We perform insertions "in-bulk", and so we might be inserting some bookmarks which need to be re-uploaded, and some bookmarks which don't. We compile an array of ContentValue objects, and make a single call to our ContentProvider. This means we can't use a URI param to indicate our intent, and so a non-column field in ContentValues objects - modifiedFromSync - is set for those bookmarks which need special treatment during insertion.
Bug 1392802 added a similar mechanism for updating bookmarks. However, updates are done differently - currently, we perform a single call to our ContentProvider for each bookmark. Which means we _can_ use a URI field as a signaling mechanism, which is what that patch did. However, in haste I forgot to take into consideration existing signaling mechanism, which lead to update failures.
And so we're left with an even clumsier interface to our data store, with two ways to signal the same thing in different circumstances... A quick solution is to just make sure 'modifiedBySync' field never makes its way to contentprovider on updates; a more refined fix would probably modify update logic to use a ContentValues field for consistency... Either way, there's going to be something ugly, somewhere in the code.
I anticipate a lot of this code changing sometime soon in order to support better transactionality of bookmark syncing, and smarter merging, and so I'm inclined to just to the simple thing for now.
MozReview-Commit-ID: H10LFsqjbFY
--HG--
extra : rebase_source : f7f311d266d75c505bb8871a567ac96d39f1b1cb
This patch moves some of the state tracking (fetchEnd/storeEnd timestamps) away from RecordsChannel
and into individual RepositorySessions. The core assumption behind this move is that
sessions are better suited to know when they were fetched from during this sync, and when they
were stored to.
Sessions are growing in complexity - local ones are wrapped in a buffer, remote
now support batching downloads and uploads. In order to hide these details, it's easier to let
sessions keep track of the fetch/store timestamps in the way that fits their implementations.
Instead of flowing these timestamps upwards from sessions and into the SynchronizerSession,
the latter now simply queries sessions at the end of their flows.
The default behavior if a certain operation wasn't performed - that is, if fetchEnd or storeEnd
aren't set during sync for a session - is to return timestamp persisted during the previous sync.
This allows us to skip certain flows (no remote data available), and ensure that we're always
using correct timestamps of the same origin for any given session.
Prior behaviour was to "make up" a timestamp at the RecordsChannel level in cases of certain
errors or skipped flows, which resulted in comparing timestamps of different origins on the consequent sync.
MozReview-Commit-ID: 2wqeTo7mhz3
--HG--
extra : rebase_source : 21b02d4164abf75422920225749ffcfd3fc71e91
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
Allow sensor to change which direction the screen is facing when using 'portrait' or 'landscape' to lock screen orientation.
MozReview-Commit-ID: 4Fqfv4bNuKD
--HG--
extra : rebase_source : 6aed9dc06b151a9bb954a0b088dbd53b8fc52154
This is the only suggested site in xxxhdpi and is thus inconsistent.
MozReview-Commit-ID: F9HvsXKsFSq
--HG--
extra : rebase_source : f7b42c5818c1e6c6012386e56f3c224c29de0966
We should use null as the profile in GeckoView.preload. We will call
GeckoProfile.initFromArgs later on in GeckoThread.getProfile, when the
profile is actually needed.
MozReview-Commit-ID: JJzIVEiuZPn
