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
Some key events synthesized from strings can have modifier metastates.
For example, from the sharp S character, we synthesize an S key with Alt
metastate. However, we don't actually want to pass the Alt metastate to
Gecko because the Alt meta key is not actually pressed in this case.
MozReview-Commit-ID: 5XYheyAgqdn
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
Even when building the "app" module in debug mode, by default Gradle still chooses to build all dependencies in release mode, which means that all of our own source files that reside in such a library (geckoview, respectively thirdparty) will e.g. be missing debug info for local variables.
MozReview-Commit-ID: owZr9yKtYI
--HG--
extra : rebase_source : ae09795ebe70bf4213cd3d145efa355712c702a0
* OSX
Make the lock of the type kIOPMAssertionTypeNoDisplaySleep and kIOPMAssertionTypeNoIdleSleep
as a singleton. Won't need to require an extra lock.
* Windows
Add |mRequireForDisplay| to ensure the "audio-playing" won't overwrite the previous
display requirement.
* Android
Add "audio-playing" and "video-playing", and make sure the audio-lock won't be cancel
when receiving "WakeLockDelegate.STATE_LOCKED_BACKGROUND".
MozReview-Commit-ID: 97oNX7H2qij
--HG--
extra : rebase_source : 24fa8b267ad97d668fa55462d1f61ef5c92b632f
In order to show download notifications, we need to initialize the
DownloadNotifications module outside of browser.js. This patch moves
initialization to BrowserCLH.js, and includes a refactoring of the
`addObserverScripts` function. The "chrome-document-interactive"
notification is used to trigger initialization because it is roughly
equivalent to where we used to initialize the module inside browser.js.
MozReview-Commit-ID: 8o1KZWRt69K
--HG--
extra : rebase_source : a588a4e0933069bbbde00dc07c97141c889dfc81
