searching for reviewer(rnewman)
df36fee2b3ac: Bug 1456487 - Update Firefox Account's first run UUID when re-connecting. r=rnewman
Nick Alexander <nalexander@mozilla.com> - Wed, 25 Apr 2018 12:17:05 -0700 - rev 471671
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1456487 - Update Firefox Account's first run UUID when re-connecting. r=rnewman The behaviour of Android Firefox Account instances recently changed in the face of system "Clear data" commands. To align more closely with common Apps like Dropbox and Whatsapp (which generally don't use Android Account instances), after a "Clear data" a Firefox Account is moved to the Separated state, requiring the user to re-connect them with a password challenge. To achieve this, newly created accounts include a first run UUID; after a "Clear data", the App is killed and restarted, Sync sees a different first run UUID, and the Account is moved to the Separated state. (I honestly don't know what happens if the Sync code never sees a different first run UUID, but that's for another day.) If the user then, in the same first run session, re-connects the Firefox Account... the Sync code will again see the different first run UUID and move the Account to the Separated state. This patch updates the first run UUID when the Account is re-connected, breaking that cycle. MozReview-Commit-ID: 9jcO9Ym54an
30867952db10: Bug 1445462 - Ensure tasks aren't scheduled during upload after flow has been aborted r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Wed, 14 Mar 2018 14:14:23 -0400 - rev 464282
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1445462 - Ensure tasks aren't scheduled during upload after flow has been aborted r=rnewman This should have been a part of Bug 1408710, but alas, here we are. Patch changes two things: - serializes process failures in BatchingUploader if record-to-be-uploaded fails sanity checks and server requirements -- this helps us short-circuit flow in RecordsChannel - avoids performing any work in ServerSession's storeDone if flow has been aborted MozReview-Commit-ID: 9qevdzRvHEx
53395fa976d3: Bug 1445462 - Pre: Clean up "ignore records on batch failure" code r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Wed, 14 Mar 2018 14:12:48 -0400 - rev 464281
Push 1728 by jlund@mozilla.com at 2018-06-18 21:12 +0000
Bug 1445462 - Pre: Clean up "ignore records on batch failure" code r=rnewman No functional change; added tests to cover the decision tree a bit better, renamed stuff. MozReview-Commit-ID: LwvyBaAg421
a803056762bb: Bug 1456487 - Update Firefox Account's first run UUID when re-connecting. r=rnewman, a=jcristau
Nick Alexander <nalexander@mozilla.com> - Wed, 25 Apr 2018 12:17:05 -0700 - rev 463578
Push 1695 by ryanvm@gmail.com at 2018-04-28 16:46 +0000
Bug 1456487 - Update Firefox Account's first run UUID when re-connecting. r=rnewman, a=jcristau The behaviour of Android Firefox Account instances recently changed in the face of system "Clear data" commands. To align more closely with common Apps like Dropbox and Whatsapp (which generally don't use Android Account instances), after a "Clear data" a Firefox Account is moved to the Separated state, requiring the user to re-connect them with a password challenge. To achieve this, newly created accounts include a first run UUID; after a "Clear data", the App is killed and restarted, Sync sees a different first run UUID, and the Account is moved to the Separated state. (I honestly don't know what happens if the Sync code never sees a different first run UUID, but that's for another day.) If the user then, in the same first run session, re-connects the Firefox Account... the Sync code will again see the different first run UUID and move the Account to the Separated state. This patch updates the first run UUID when the Account is re-connected, breaking that cycle. MozReview-Commit-ID: 9jcO9Ym54an
2d9c633028ad: Bug 1445462 - Ensure tasks aren't scheduled during upload after flow has been aborted. r=rnewman, a=jcristau
Grigory Kruglov <gkruglov@mozilla.com> - Wed, 14 Mar 2018 14:14:23 -0400 - rev 462812
Push 1683 by sfraser@mozilla.com at 2018-04-26 16:43 +0000
Bug 1445462 - Ensure tasks aren't scheduled during upload after flow has been aborted. r=rnewman, a=jcristau This should have been a part of Bug 1408710, but alas, here we are. Patch changes two things: - serializes process failures in BatchingUploader if record-to-be-uploaded fails sanity checks and server requirements -- this helps us short-circuit flow in RecordsChannel - avoids performing any work in ServerSession's storeDone if flow has been aborted MozReview-Commit-ID: 9qevdzRvHEx
ab70ed8311a2: Bug 1445462 - Pre: Clean up "ignore records on batch failure" code. r=rnewman, a=jcristau
Grigory Kruglov <gkruglov@mozilla.com> - Wed, 14 Mar 2018 14:12:48 -0400 - rev 462811
Push 1683 by sfraser@mozilla.com at 2018-04-26 16:43 +0000
Bug 1445462 - Pre: Clean up "ignore records on batch failure" code. r=rnewman, a=jcristau No functional change; added tests to cover the decision tree a bit better, renamed stuff. MozReview-Commit-ID: LwvyBaAg421
ef963ffb6d1b: Bug 1408710 - Don't pass around GUIDs of individual record store success, just an aggregate counter r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Mon, 26 Feb 2018 15:12:21 -0500 - rev 460434
Push 1683 by sfraser@mozilla.com at 2018-04-26 16:43 +0000
Bug 1408710 - Don't pass around GUIDs of individual record store success, just an aggregate counter r=rnewman We don't use these GUIDs anywhere, and this change lets us kill off some expensive data structures necessary to maintain lists of successfully uploaded GUIDs, particularly during an upload. MozReview-Commit-ID: F0kcY8o8DUw
a2227052b4aa: Bug 1408710 - Serialize RecordsChannel r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Mon, 26 Feb 2018 15:12:34 -0500 - rev 460433
Push 1683 by sfraser@mozilla.com at 2018-04-26 16:43 +0000
Bug 1408710 - Serialize RecordsChannel r=rnewman This patch does two things: - serializes flow of records through the RecordsChannel - simplifies the batching logic The two are connected: rather than queuing records in ConcurrentLinkedQueue, we now buffer downloaded records in an ArrayList, and deliver them to the receiving repository all at once. Doing this work right at the channel level lets us kill off the buffering middleware. An addition of a NonBufferingSyncStage lets individual SyncStages use a RecordsChannel which doesn't perform any kind of buffering. Prior, stages did this by wrapping their receiving repositories in the buffering middleware. The main goal is to speed up the flow of records, keep within the same memory footprint and do some simplification in the process. This patch explicitly does not address the delegated nature of fetch and store, which is now largely irrelevant. MozReview-Commit-ID: J2afmgr1Td1
430a0bfcdb93: Bug 1408710 - Pre: for clarity, rename session's delegateQueue to a more appropriate name r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Fri, 05 Jan 2018 16:54:53 -0500 - rev 460432
Push 1683 by sfraser@mozilla.com at 2018-04-26 16:43 +0000
Bug 1408710 - Pre: for clarity, rename session's delegateQueue to a more appropriate name r=rnewman From the point of view of the session itself, this queue is named correctly (e.g. session's abort and finish methods make sure invoke success and failure delegate methods from this queue). However, from the point of view of every concrete implementation of the session, the current naming isn't clear. New name is for symmetry with the store queue, and the above ambiquity is addressed in the comment. MozReview-Commit-ID: 61j7ZCNdr4x
82986cd4578a: Bug 1408710 - Pre: Just use the delegateQueue in the downloader instead of creating a new one r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Fri, 05 Jan 2018 16:41:20 -0500 - rev 460431
Push 1683 by sfraser@mozilla.com at 2018-04-26 16:43 +0000
Bug 1408710 - Pre: Just use the delegateQueue in the downloader instead of creating a new one r=rnewman This is a clean-up. Everywhere else, we run the fetch tasks and corresponding delegates on the delegateQueue. MozReview-Commit-ID: Kd8XZAclJIB
42ccbb911db3: Bug 1408710 - Pre: Remove ServerLocalSynchronizer* r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Tue, 14 Nov 2017 15:29:57 -0500 - rev 460430
Push 1683 by sfraser@mozilla.com at 2018-04-26 16:43 +0000
Bug 1408710 - Pre: Remove ServerLocalSynchronizer* r=rnewman Theoretical ability to setup synchronizers other than server->local never really manifested itself in anything actually useful, and I don't foresee that design choice as currently expressed being useful in the near future. So, let's take a moment to clear up the layers a little bit. MozReview-Commit-ID: 5fIZc6zYeit
d3363d47276b: Bug 1437416 - remove dead code that attempted to provide a default salt and verify the code actually works regardless. r=rfkelly,rnewman
Mark Hammond <mhammond@skippinet.com.au> - Thu, 15 Feb 2018 11:55:32 +1100 - rev 459984
Push 1683 by sfraser@mozilla.com at 2018-04-26 16:43 +0000
Bug 1437416 - remove dead code that attempted to provide a default salt and verify the code actually works regardless. r=rfkelly,rnewman MozReview-Commit-ID: GKII0jjVtSf
dc3f1141af95: Bug 1431260 - Switch Android code to read multilocale.txt. r=rnewman
Zibi Braniecki <zbraniecki@mozilla.com> - Tue, 13 Feb 2018 23:42:34 -0800 - rev 459732
Push 1683 by sfraser@mozilla.com at 2018-04-26 16:43 +0000
Bug 1431260 - Switch Android code to read multilocale.txt. r=rnewman MozReview-Commit-ID: 6S4VaAvDako
3b57cf8b3767: Bug 1305563 - Add a bookmark mirror and two-way merger for synced bookmarks. r=mak,markh,rnewman,tcsc
Kit Cambridge <kit@yakshaving.ninja> - Sat, 06 Jan 2018 07:44:33 -0800 - rev 456026
Push 1683 by sfraser@mozilla.com at 2018-04-26 16:43 +0000
Bug 1305563 - Add a bookmark mirror and two-way merger for synced bookmarks. r=mak,markh,rnewman,tcsc The mirror matches the complete bookmark tree stored on the Sync server, stores new bookmarks changed on the server since the last sync, merges the local and remote trees, applies the resulting merged tree back to Places, fires observer notifications for all items changed in the merge, and stages locally changed bookmarks for upload. MozReview-Commit-ID: MbeFQUargt
b2c761bbd3d6: Bug 1430647 - Remove remaining uses of -moz-border-*-colors from android themes. r=rnewman,snorp
Dão Gottwald <dao@mozilla.com> - Mon, 15 Jan 2018 20:36:31 +0100 - rev 455242
Push 1683 by sfraser@mozilla.com at 2018-04-26 16:43 +0000
Bug 1430647 - Remove remaining uses of -moz-border-*-colors from android themes. r=rnewman,snorp MozReview-Commit-ID: eKGucTqWei
197515c59832: Bug 1421547 - Remove remaining traces of the old toolkit.telemetry.enabledPreRelease pref. r=rnewman
Nicholas Nethercote <nnethercote@mozilla.com> - Fri, 01 Dec 2017 22:23:49 +1100 - rev 448816
Push 1648 by mtabara@mozilla.com at 2018-03-01 12:45 +0000
Bug 1421547 - Remove remaining traces of the old toolkit.telemetry.enabledPreRelease pref. r=rnewman The code to migrate from the toolkit.telemetry.enabledPreRelease pref to toolkit.telemetry.enabled was added to Firefox 31 in bug 986582. It should be safe to remove now. MozReview-Commit-ID: JBkn20bUQXx
526f6a68b77d: Bug 1408585 - Remove RepositorySession createSession delegates r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Tue, 14 Nov 2017 14:37:05 -0500 - rev 446064
Push 1648 by mtabara@mozilla.com at 2018-03-01 12:45 +0000
Bug 1408585 - Remove RepositorySession createSession delegates r=rnewman MozReview-Commit-ID: KezYHeSWDiL
421ecf591543: Bug 1408585 - Remove RepositorySession begin delegates r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Mon, 13 Nov 2017 14:29:49 -0500 - rev 446063
Push 1648 by mtabara@mozilla.com at 2018-03-01 12:45 +0000
Bug 1408585 - Remove RepositorySession begin delegates r=rnewman 'begin' now throws in case things go wrong. MozReview-Commit-ID: 8jcxYiPcsii
50fbdae0bcd6: Bug 1331290 - Refactor the code about closing all opening tabs. r=JanH,rnewman
Nevin Chen <cnevinchen@gmail.com> - Thu, 21 Sep 2017 14:12:40 +0800 - rev 440860
Push 1618 by Callek@gmail.com at 2018-01-11 17:45 +0000
Bug 1331290 - Refactor the code about closing all opening tabs. r=JanH,rnewman MozReview-Commit-ID: LxcY1MyOypF
984d5493a4b3: Bug 1403022 - Abort session on BatchingUploader failures r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Tue, 26 Sep 2017 17:36:22 -0400 - rev 436370
Push 1618 by Callek@gmail.com at 2018-01-11 17:45 +0000
Bug 1403022 - Abort session on BatchingUploader failures r=rnewman The main goal of these changes is to ensure we're not doing any unnecessary work in the unahppy cases of BatchingUploader. We might fail in three general ways: - encounter a 412 error - encounter another type of HTTP error - encounter a GUID in the "failed" array Currently, in all of these cases, we de-facto abort the session, without performing an actual abort. E.g. we won't commit a batch, we'll refuse to upload any still-flowing records. This patch simplifies our unhappy-case behaviour: if something failed, actually abort the session (triggering a shutdownNow of the work queues), declare store as failed, etc. It's important to note that our "did the synchronization fail?" login in the SynchronizerSession depends on the store failure counts, and so this patch maintains the "record failed to store" delegate chain. However, these counts are largely meaningless. What does it mean to fail to store 50 records, if we abort on the 51st, and prevent the other 100 from flowing (and from being counted as failed?). This patch also fixes an omission in the verstion tracking logic: - prior, if we encountered a record in the "failed" array, we'd continue on with the flow, won't upload anything, mark the synchronization as failed, but we'd also call into 'onStoreCompleted' which will trigger an update of syncVersion for outflowing records - with this patch, we won't call into onStoreCompleted in the case above, and so won't update syncVersion in case of such failures - this is the correct behaviour for batching uploads (now enabled on all but one server), but possibly non-optimal behaviour if batching isn't enabled. However, this behaviour should be safe from a data consistency point of view regardless of the batching mode. MozReview-Commit-ID: LIYCPaRX8JA
82a3a8ca311e: Bug 1373254 - Ensure onStoreFailed won't be called twice r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Mon, 25 Sep 2017 20:01:14 -0400 - rev 436073
Push 1618 by Callek@gmail.com at 2018-01-11 17:45 +0000
Bug 1373254 - Ensure onStoreFailed won't be called twice r=rnewman MozReview-Commit-ID: 5IE7t5qs6VU
cd91b8be78f6: Bug 1351673 - Use a single-threaded work queue to process batching downloader work items r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Thu, 21 Sep 2017 16:53:03 -0400 - rev 435545
Push 1618 by Callek@gmail.com at 2018-01-11 17:45 +0000
Bug 1351673 - Use a single-threaded work queue to process batching downloader work items r=rnewman Before we'd recurse instead while fetching multiple batches, overflowing the stack on older devices. MozReview-Commit-ID: 37BG6zGBdn0
e84c811afec6: Bug 1373254 - Ensure onStoreFailed won't be called twice. r=rnewman, a=sledru
Grigory Kruglov <gkruglov@mozilla.com> - Mon, 25 Sep 2017 20:01:14 -0400 - rev 434303
Push 1567 by jlorenzo@mozilla.com at 2017-11-02 12:36 +0000
Bug 1373254 - Ensure onStoreFailed won't be called twice. r=rnewman, a=sledru MozReview-Commit-ID: 5IE7t5qs6VU
9767e159a701: Bug 1351673 - Use a single-threaded work queue to process batching downloader work items r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Wed, 20 Sep 2017 22:21:02 -0400 - rev 434071
Push 1567 by jlorenzo@mozilla.com at 2017-11-02 12:36 +0000
Bug 1351673 - Use a single-threaded work queue to process batching downloader work items r=rnewman Before we'd recurse instead while fetching multiple batches, overflowing the stack on older devices. MozReview-Commit-ID: 37BG6zGBdn0
96dab44be3ba: Bug 1351673 - Use a single-threaded work queue to process batching downloader work items r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Wed, 20 Sep 2017 19:59:23 -0400 - rev 434061
Push 1567 by jlorenzo@mozilla.com at 2017-11-02 12:36 +0000
Bug 1351673 - Use a single-threaded work queue to process batching downloader work items r=rnewman Before we'd recurse instead while fetching multiple batches, overflowing the stack on older devices. MozReview-Commit-ID: 37BG6zGBdn0
cf262990357e: Bug 1397925 - Refresh OSPreferences mSystemLocales when intl.locale.os changes. r=rnewman
Zibi Braniecki <zbraniecki@mozilla.com> - Thu, 07 Sep 2017 14:53:36 -0700 - rev 431776
Push 1567 by jlorenzo@mozilla.com at 2017-11-02 12:36 +0000
Bug 1397925 - Refresh OSPreferences mSystemLocales when intl.locale.os changes. r=rnewman MozReview-Commit-ID: oJdWUXwhZw
1576df4c449c: Bug 1396544 - don't schedule syncs when Sync isn't configured. r=rnewman
Mark Hammond <mhammond@skippinet.com.au> - Tue, 05 Sep 2017 12:40:53 +1000 - rev 431056
Push 1567 by jlorenzo@mozilla.com at 2017-11-02 12:36 +0000
Bug 1396544 - don't schedule syncs when Sync isn't configured. r=rnewman MozReview-Commit-ID: AM0G43vFyty
b18cad4e3274: Bug 1395703 - Make sure modifiedBySync CV field isn't passed to ContentProvider on updates r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Thu, 31 Aug 2017 18:05:20 -0400 - rev 430054
Push 1567 by jlorenzo@mozilla.com at 2017-11-02 12:36 +0000
Bug 1395703 - Make sure modifiedBySync CV field isn't passed to ContentProvider on updates r=rnewman 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
5f2aa1dd303e: Bug 1392505 - Let RepositorySessions track their own lastFetch and lastStore timestamps r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Wed, 30 Aug 2017 19:48:21 -0400 - rev 429812
Push 1567 by jlorenzo@mozilla.com at 2017-11-02 12:36 +0000
Bug 1392505 - Let RepositorySessions track their own lastFetch and lastStore timestamps r=rnewman 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
63093a78771f: Bug 1392505 - Pre: remove unused delegate interface r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Fri, 25 Aug 2017 21:44:37 -0400 - rev 429811
Push 1567 by jlorenzo@mozilla.com at 2017-11-02 12:36 +0000
Bug 1392505 - Pre: remove unused delegate interface r=rnewman MozReview-Commit-ID: K93rK1pILky
a33490d5a193: Bug 1392802 - Increment localVersion while reconciling a bookmark if we modified its dateAdded t.s. r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Tue, 29 Aug 2017 20:12:46 -0400 - rev 429800
Push 1567 by jlorenzo@mozilla.com at 2017-11-02 12:36 +0000
Bug 1392802 - Increment localVersion while reconciling a bookmark if we modified its dateAdded t.s. r=rnewman 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
ba4778825623: Bug 1388884 - Do not delete bookmark tombstones r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Tue, 29 Aug 2017 14:01:14 -0400 - rev 429577
Push 1567 by jlorenzo@mozilla.com at 2017-11-02 12:36 +0000
Bug 1388884 - Do not delete bookmark tombstones r=rnewman As implemented, this means we might upload tombstones for never-synced bookmarks. This _should_ be harmless. MozReview-Commit-ID: DZx9yWDs1ie
f4ce8ee833e9: Bug 1394073 - Call onStoreFailed in case last payload fails in the uploader r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Fri, 25 Aug 2017 21:41:35 -0400 - rev 429268
Push 1567 by jlorenzo@mozilla.com at 2017-11-02 12:36 +0000
Bug 1394073 - Call onStoreFailed in case last payload fails in the uploader r=rnewman MozReview-Commit-ID: 9cRuevmqbLD
aae46de1a7cf: Bug 1392716 - Clean up version map while de-duping records r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Wed, 23 Aug 2017 21:28:49 -0400 - rev 428482
Push 1567 by jlorenzo@mozilla.com at 2017-11-02 12:36 +0000
Bug 1392716 - Clean up version map while de-duping records r=rnewman This is meant as a stop-gap measure to stop the obviously bad thing from happening. MozReview-Commit-ID: Gqvc32K04xD
c7e972957ff0: Bug 1392078 - More detailed strong assertions to help narrow down root cause r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Mon, 21 Aug 2017 17:42:44 -0400 - rev 427999
Push 1567 by jlorenzo@mozilla.com at 2017-11-02 12:36 +0000
Bug 1392078 - More detailed strong assertions to help narrow down root cause r=rnewman MozReview-Commit-ID: JSN9Q837u6R
139c4e2e2d0e: Bug 1364644 - Post: remove AndroidBrowser prefix from class names r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Mon, 14 Aug 2017 21:21:29 -0400 - rev 427195
Push 1567 by jlorenzo@mozilla.com at 2017-11-02 12:36 +0000
Bug 1364644 - Post: remove AndroidBrowser prefix from class names r=rnewman MozReview-Commit-ID: Bpgba2BR7hp
517c934fdec5: Bug 1364644 - Versioned syncing of bookmarks r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Wed, 16 Aug 2017 21:02:21 -0400 - rev 427194
Push 1567 by jlorenzo@mozilla.com at 2017-11-02 12:36 +0000
Bug 1364644 - Versioned syncing of bookmarks r=rnewman MozReview-Commit-ID: 5IdRPUXMDPh
b5631dd590ae: Bug 1364644 - Bookmark version tracking r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Tue, 15 Aug 2017 17:28:56 -0400 - rev 427193
Push 1567 by jlorenzo@mozilla.com at 2017-11-02 12:36 +0000
Bug 1364644 - Bookmark version tracking r=rnewman MozReview-Commit-ID: EdN4pYSR8Ux
866bf0a5a6b6: Bug 1364644 - Migrate bookmarks schema and records to add version columns r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Mon, 14 Aug 2017 23:22:53 -0400 - rev 427192
Push 1567 by jlorenzo@mozilla.com at 2017-11-02 12:36 +0000
Bug 1364644 - Migrate bookmarks schema and records to add version columns r=rnewman Schema migration is simple: it adds localVersion and syncVersion columns to bookmarks table. Default values are: - localVersion=1 - syncVersion=0 ... indicating that a record needs to be uploaded. Data migration is also relatively simple: we need to ensure that records which are "up-to-date", according to the old timestamp-based tracking, are not marked for an upload, and vice versa - records which are either "new" or "changed" are marked for an upload. Since our default during schema migration is to mark everything for upload, the data migration concerns itself with the records which are considered as "up-to-date". See detailed description in the comments in the data migration function. MozReview-Commit-ID: J6aglurYwlo
d7e7927feaf3: Bug 1364644 - Pre: Refactor bookmark and history sessions to allow for different superclasses r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Fri, 04 Aug 2017 18:43:49 -0400 - rev 427191
Push 1567 by jlorenzo@mozilla.com at 2017-11-02 12:36 +0000
Bug 1364644 - Pre: Refactor bookmark and history sessions to allow for different superclasses r=rnewman Versioned syncing work later in the patch series introduces functionality that is best suited to live within the RepositorySession inheritance chain. We'd like to introduce a new RepositorySession subclass which individual RepositorySessions are able to inherit. And that's when the current inheritance structure gets in the way: history and bookmarks both share a superclass, and we'd like to only introduce this new functionality for bookmarks. This makes our task, as stated, impossible without breaking apart the current inheritance structure. This patch introduces a few "delegate" objects: - SessionHelper --> HistorySessionHelper --> BookmarksSessionHelper ... which absorb most of the functionality from AndroidBrowserRepositorySession (removed) and bookmark and history repository sessions. This change is not functional - everything remains as before otherwise. MozReview-Commit-ID: 7WwUmY3Wql7
210d26d08294: Bug 1364644 - Pre: don't swallow runtime exceptions in the BrowserProvider's call interface r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Thu, 27 Jul 2017 00:28:08 -0400 - rev 427190
Push 1567 by jlorenzo@mozilla.com at 2017-11-02 12:36 +0000
Bug 1364644 - Pre: don't swallow runtime exceptions in the BrowserProvider's call interface r=rnewman MozReview-Commit-ID: 3mgOrSvEFxU
2f69b4cb829c: Bug 1364644 - Pre: Move change tracking responsibilities into repositories r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Fri, 28 Jul 2017 17:15:22 -0400 - rev 427189
Push 1567 by jlorenzo@mozilla.com at 2017-11-02 12:36 +0000
Bug 1364644 - Pre: Move change tracking responsibilities into repositories r=rnewman As part of moving toward versioned syncing, we need to start decoupling change tracking concepts from parts of the system that facilitate flow of records. This allows us to track what changed differently for different data types, while maintaining a consistent and predictable API. A move toward that is to let repositories own determinining that a record has been modified. Repositories are now asked to provide modified records, instead of a very specific "records modified since". This patch does not change behaviour of the system: every repository still uses timestamp-based change tracking to actually provide modified records to the caller. A changeover to version tracking will come later in this series for bookmarks, and as part of Bug 1383894 for other repositories. MozReview-Commit-ID: LQuWYdlNHpt
3846782bf831: Bug 1364644 - Pre: Remove guidsSince RepositorySession interface r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Mon, 24 Jul 2017 14:48:38 -0400 - rev 427188
Push 1567 by jlorenzo@mozilla.com at 2017-11-02 12:36 +0000
Bug 1364644 - Pre: Remove guidsSince RepositorySession interface r=rnewman We're moving toward version-based syncing. This is one of the bricks in that road, removing an unused timestamp-based interface for accessing changed records. MozReview-Commit-ID: CYUyASWXrMW
2b09cdaae71c: Bug 1386027 - Simplify handleError interfaces for SessionCallback and TelemetryCollector r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Tue, 08 Aug 2017 13:45:29 -0400 - rev 425433
Push 1567 by jlorenzo@mozilla.com at 2017-11-02 12:36 +0000
Bug 1386027 - Simplify handleError interfaces for SessionCallback and TelemetryCollector r=rnewman Error reporting, and especially the split between per-stage and global session errors, are a bit of a mess; at the very least, this patch unifies things a little bit, and ensures we're not passing around nulls unexpectedly. MozReview-Commit-ID: JTSp7GuOji0
513dfaefa408: Bug 1387053 - Make sure we don't do DB migration multiple times. r=rnewman
Edouard Oger <eoger@fastmail.com> - Thu, 03 Aug 2017 11:04:44 -0400 - rev 424637
Push 1567 by jlorenzo@mozilla.com at 2017-11-02 12:36 +0000
Bug 1387053 - Make sure we don't do DB migration multiple times. r=rnewman MozReview-Commit-ID: I799FUjIG4M
aa3740564226: Bug 1397925 - Refresh OSPreferences mSystemLocales when intl.locale.os changes. r=rnewman, a=lizzard
Zibi Braniecki <zbraniecki@mozilla.com> - Thu, 07 Sep 2017 14:53:36 -0700 - rev 424062
Push 1517 by jlorenzo@mozilla.com at 2017-09-14 16:50 +0000
Bug 1397925 - Refresh OSPreferences mSystemLocales when intl.locale.os changes. r=rnewman, a=lizzard MozReview-Commit-ID: oJdWUXwhZw
2eabe4c12b9a: Bug 1386027 - Simplify handleError interfaces for SessionCallback and TelemetryCollector. r=rnewman, a=lizzard
Grigory Kruglov <gkruglov@mozilla.com> - Tue, 08 Aug 2017 13:45:29 -0400 - rev 423488
Push 1517 by jlorenzo@mozilla.com at 2017-09-14 16:50 +0000
Bug 1386027 - Simplify handleError interfaces for SessionCallback and TelemetryCollector. r=rnewman, a=lizzard Error reporting, and especially the split between per-stage and global session errors, are a bit of a mess; at the very least, this patch unifies things a little bit, and ensures we're not passing around nulls unexpectedly. MozReview-Commit-ID: JTSp7GuOji0
0d580486af34: Bug 1384936 - Remove weave_version definition and directly replace the constant in modules/constants.js in the gecko migration script, to avoid the need for the preprocessor in modules/constants.js. r=rnewman,rail
Marco Castelluccio <mcastelluccio@mozilla.com> - Thu, 27 Jul 2017 16:22:53 +0200 - rev 422692
Push 1517 by jlorenzo@mozilla.com at 2017-09-14 16:50 +0000
Bug 1384936 - Remove weave_version definition and directly replace the constant in modules/constants.js in the gecko migration script, to avoid the need for the preprocessor in modules/constants.js. r=rnewman,rail
9bc216bce3c6: Bug 1316462 - Increase minsdk to 16 and remove EOL notification. r=sebastian, r=snorp, r=rnewman
maliu <max@mxli.us> - Thu, 27 Jul 2017 08:27:08 -0400 - rev 422499
Push 1517 by jlorenzo@mozilla.com at 2017-09-14 16:50 +0000
Bug 1316462 - Increase minsdk to 16 and remove EOL notification. r=sebastian, r=snorp, r=rnewman MozReview-Commit-ID: 7o1xqIqVWC6
77a37c261feb: Bug 1373818 - Don't hardcode our tracker per Adjust. r=rnewman
Michael Kaply <mozilla@kaply.com> - Fri, 07 Jul 2017 14:27:58 -0500 - rev 421011
Push 1517 by jlorenzo@mozilla.com at 2017-09-14 16:50 +0000
Bug 1373818 - Don't hardcode our tracker per Adjust. r=rnewman MozReview-Commit-ID: 5O04Qp2IP9U