searching for reviewer(rnewman)
df36fee2b3acada69d9bd43b4febc48707adc801: 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 415590
Push 33900 by dluca@mozilla.com at Thu, 26 Apr 2018 04:51:04 +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
30867952db101a3083b61699ddc97a40b804d6ea: 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 408201
Push 33629 by shindli@mozilla.com at Thu, 15 Mar 2018 09:58:11 +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
53395fa976d3643bbf79a58b172732c27a1306c9: 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 408200
Push 33629 by shindli@mozilla.com at Thu, 15 Mar 2018 09:58:11 +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
ef963ffb6d1b214b9c7f7687012a0698ab018a7b: 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 405432
Push 33519 by aiakab@mozilla.com at Tue, 27 Feb 2018 09:56:16 +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
a2227052b4aa09a3b14aed01ff48f6e525904cb3: Bug 1408710 - Serialize RecordsChannel r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Mon, 26 Feb 2018 15:12:34 -0500 - rev 405431
Push 33519 by aiakab@mozilla.com at Tue, 27 Feb 2018 09:56:16 +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
430a0bfcdb9372d4d56845ac5c7e330d96f421ab: 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 405430
Push 33519 by aiakab@mozilla.com at Tue, 27 Feb 2018 09:56:16 +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
82986cd4578a8a93010c97ac69ccfd9805fdb930: 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 405429
Push 33519 by aiakab@mozilla.com at Tue, 27 Feb 2018 09:56:16 +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
42ccbb911db3b7f5393dbf5dae6c31c53d4887df: Bug 1408710 - Pre: Remove ServerLocalSynchronizer* r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Tue, 14 Nov 2017 15:29:57 -0500 - rev 405428
Push 33519 by aiakab@mozilla.com at Tue, 27 Feb 2018 09:56:16 +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
d3363d47276bf078c00d6d3bd9d231ebbce4c4b4: 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 404982
Push 33498 by ccoroiu@mozilla.com at Fri, 23 Feb 2018 17:42:25 +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
dc3f1141af957b96076f69640c518ed89e20a3f3: 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 404730
Push 33489 by dluca@mozilla.com at Thu, 22 Feb 2018 09:59:00 +0000
Bug 1431260 - Switch Android code to read multilocale.txt. r=rnewman MozReview-Commit-ID: 6S4VaAvDako
3b57cf8b376704aeb9591a9e048ce8c9083a6f1f: 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 401024
Push 33327 by csabou@mozilla.com at Sat, 27 Jan 2018 09:53:36 +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
b2c761bbd3d67aac3f1b417c742b530df0e18c06: 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 400240
Push 33299 by rgurzau@mozilla.com at Tue, 23 Jan 2018 00:22:17 +0000
Bug 1430647 - Remove remaining uses of -moz-border-*-colors from android themes. r=rnewman,snorp MozReview-Commit-ID: eKGucTqWei
197515c59832ddadf946ef99ea1c4353735413a9: 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 394544
Push 33008 by aciure@mozilla.com at Sat, 02 Dec 2017 09:47:20 +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
526f6a68b77d340db9ec41f828ce1eeeb91aa5fb: Bug 1408585 - Remove RepositorySession createSession delegates r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Tue, 14 Nov 2017 14:37:05 -0500 - rev 391792
Push 32904 by nerli@mozilla.com at Wed, 15 Nov 2017 09:56:19 +0000
Bug 1408585 - Remove RepositorySession createSession delegates r=rnewman MozReview-Commit-ID: KezYHeSWDiL
421ecf5915434aac48675ecc5ab8b6ca6c089a15: Bug 1408585 - Remove RepositorySession begin delegates r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Mon, 13 Nov 2017 14:29:49 -0500 - rev 391791
Push 32904 by nerli@mozilla.com at Wed, 15 Nov 2017 09:56:19 +0000
Bug 1408585 - Remove RepositorySession begin delegates r=rnewman 'begin' now throws in case things go wrong. MozReview-Commit-ID: 8jcxYiPcsii
50fbdae0bcd66a2cd67c89df4fcc768aada1fdac: 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 387612
Push 32732 by archaeopteryx@coole-files.de at Mon, 23 Oct 2017 21:48:58 +0000
Bug 1331290 - Refactor the code about closing all opening tabs. r=JanH,rnewman MozReview-Commit-ID: LxcY1MyOypF
984d5493a4b3a4d6b55a9ad6a83dba51ce73d250: Bug 1403022 - Abort session on BatchingUploader failures r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Tue, 26 Sep 2017 17:36:22 -0400 - rev 383122
Push 32583 by archaeopteryx@coole-files.de at Wed, 27 Sep 2017 09:46:12 +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
82a3a8ca311e5a814537c75eaf093a38f975f420: 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 382825
Push 32576 by archaeopteryx@coole-files.de at Tue, 26 Sep 2017 09:52:21 +0000
Bug 1373254 - Ensure onStoreFailed won't be called twice r=rnewman MozReview-Commit-ID: 5IE7t5qs6VU
cd91b8be78f6026f0fabd0ea2566aef82543b1ec: 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 382297
Push 32553 by philringnalda@gmail.com at Fri, 22 Sep 2017 03:40:16 +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
9767e159a7018465824b7f6e4d504875cfa5cc6b: 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 382087
Push 32546 by archaeopteryx@coole-files.de at Thu, 21 Sep 2017 13:14:27 +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
96dab44be3bab04b2b56f29b6a2749630735d382: 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 382077
Push 32546 by archaeopteryx@coole-files.de at Thu, 21 Sep 2017 13:14:27 +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
cf262990357ed11df3aa3c6794eb751f4e4b2813: 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 379817
Push 32463 by archaeopteryx@coole-files.de at Sat, 09 Sep 2017 09:43:48 +0000
Bug 1397925 - Refresh OSPreferences mSystemLocales when intl.locale.os changes. r=rnewman MozReview-Commit-ID: oJdWUXwhZw
1576df4c449ce07ba05a1aa0b0dc9eb4ca35fea7: 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 379097
Push 32448 by archaeopteryx@coole-files.de at Wed, 06 Sep 2017 09:24:33 +0000
Bug 1396544 - don't schedule syncs when Sync isn't configured. r=rnewman MozReview-Commit-ID: AM0G43vFyty
b18cad4e3274cb2a6b92eb95779f099b79c4fd5d: 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 378095
Push 32421 by archaeopteryx@coole-files.de at Fri, 01 Sep 2017 08:31:26 +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
5f2aa1dd303e5844bc9c2b1908f4581464329625: 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 377853
Push 32416 by archaeopteryx@coole-files.de at Thu, 31 Aug 2017 12:35:23 +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
63093a78771fea17884a567d90aaff7cd62b2a9c: Bug 1392505 - Pre: remove unused delegate interface r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Fri, 25 Aug 2017 21:44:37 -0400 - rev 377852
Push 32416 by archaeopteryx@coole-files.de at Thu, 31 Aug 2017 12:35:23 +0000
Bug 1392505 - Pre: remove unused delegate interface r=rnewman MozReview-Commit-ID: K93rK1pILky
a33490d5a1933a3a84d807bbd0bbcab85361ccad: 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 377841
Push 32416 by archaeopteryx@coole-files.de at Thu, 31 Aug 2017 12:35:23 +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
ba47788256231b05118b3b9a7e022c86caa813a9: Bug 1388884 - Do not delete bookmark tombstones r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Tue, 29 Aug 2017 14:01:14 -0400 - rev 377618
Push 32412 by archaeopteryx@coole-files.de at Wed, 30 Aug 2017 08:45:09 +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
f4ce8ee833e9a332ba383377587c69e39ebff9cc: 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 377309
Push 32407 by archaeopteryx@coole-files.de at Tue, 29 Aug 2017 18:28:36 +0000
Bug 1394073 - Call onStoreFailed in case last payload fails in the uploader r=rnewman MozReview-Commit-ID: 9cRuevmqbLD
aae46de1a7cf9f01464a04cd610ddfbbb93d7fb4: 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 376523
Push 32384 by archaeopteryx@coole-files.de at Thu, 24 Aug 2017 11:27:12 +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
c7e972957ff0d3f8d427c827d0536757055420df: 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 376040
Push 32371 by archaeopteryx@coole-files.de at Tue, 22 Aug 2017 09:47:47 +0000
Bug 1392078 - More detailed strong assertions to help narrow down root cause r=rnewman MozReview-Commit-ID: JSN9Q837u6R
139c4e2e2d0e95aecf390b9a7510fc6b4f3f3a8f: 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 375236
Push 32350 by cbook@mozilla.com at Thu, 17 Aug 2017 11:02:43 +0000
Bug 1364644 - Post: remove AndroidBrowser prefix from class names r=rnewman MozReview-Commit-ID: Bpgba2BR7hp
517c934fdec51acaa7cea69f949443e444f9691b: Bug 1364644 - Versioned syncing of bookmarks r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Wed, 16 Aug 2017 21:02:21 -0400 - rev 375235
Push 32350 by cbook@mozilla.com at Thu, 17 Aug 2017 11:02:43 +0000
Bug 1364644 - Versioned syncing of bookmarks r=rnewman MozReview-Commit-ID: 5IdRPUXMDPh
b5631dd590ae14433676d09eb28fa75374f623dc: Bug 1364644 - Bookmark version tracking r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Tue, 15 Aug 2017 17:28:56 -0400 - rev 375234
Push 32350 by cbook@mozilla.com at Thu, 17 Aug 2017 11:02:43 +0000
Bug 1364644 - Bookmark version tracking r=rnewman MozReview-Commit-ID: EdN4pYSR8Ux
866bf0a5a6b6e8bb787fe6addc9798b62f656f73: 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 375233
Push 32350 by cbook@mozilla.com at Thu, 17 Aug 2017 11:02:43 +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
d7e7927feaf3ec07ff60963149f4664d12212d5e: 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 375232
Push 32350 by cbook@mozilla.com at Thu, 17 Aug 2017 11:02:43 +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
210d26d082942f10d706e357aa46d682c974aa65: 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 375231
Push 32350 by cbook@mozilla.com at Thu, 17 Aug 2017 11:02:43 +0000
Bug 1364644 - Pre: don't swallow runtime exceptions in the BrowserProvider's call interface r=rnewman MozReview-Commit-ID: 3mgOrSvEFxU
2f69b4cb829c71fb76f4006d16f7982308af400a: 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 375230
Push 32350 by cbook@mozilla.com at Thu, 17 Aug 2017 11:02:43 +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
3846782bf831982536fe0c62533563a7c9187a73: Bug 1364644 - Pre: Remove guidsSince RepositorySession interface r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Mon, 24 Jul 2017 14:48:38 -0400 - rev 375229
Push 32350 by cbook@mozilla.com at Thu, 17 Aug 2017 11:02:43 +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
2b09cdaae71cf5e2f98825ce960954eb1c36a435: 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 373474
Push 32303 by cbook@mozilla.com at Wed, 09 Aug 2017 09:34:07 +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
513dfaefa408b2ffbb6d830e6274ba679831caa0: 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 372678
Push 32282 by kwierso@gmail.com at Fri, 04 Aug 2017 00:01:29 +0000
Bug 1387053 - Make sure we don't do DB migration multiple times. r=rnewman MozReview-Commit-ID: I799FUjIG4M
0d580486af34eb697ae8de1610c6e92cddb361fb: 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 371584
Push 32250 by cbook@mozilla.com at Fri, 28 Jul 2017 13:24:57 +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
9bc216bce3c6cb524c3937a66fa923e1a8b0894e: 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 371391
Push 32245 by kwierso@gmail.com at Thu, 27 Jul 2017 22:44:21 +0000
Bug 1316462 - Increase minsdk to 16 and remove EOL notification. r=sebastian, r=snorp, r=rnewman MozReview-Commit-ID: 7o1xqIqVWC6
77a37c261feb8933a995fbcb6aa64812f83ed3cb: 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 369903
Push 32208 by archaeopteryx@coole-files.de at Fri, 21 Jul 2017 09:12:51 +0000
Bug 1373818 - Don't hardcode our tracker per Adjust. r=rnewman MozReview-Commit-ID: 5O04Qp2IP9U
a8bbfc7c430ccae947312f46604943a9f354833d: Bug 1374200 - [1.0] Use custom URI scheme normalization to work around API level 16 restriction. r=rnewman
Eugen Sawin <esawin@mozilla.com> - Wed, 21 Jun 2017 19:11:39 +0200 - rev 365432
Push 32072 by cbook@mozilla.com at Thu, 22 Jun 2017 10:47:53 +0000
Bug 1374200 - [1.0] Use custom URI scheme normalization to work around API level 16 restriction. r=rnewman
12f0f85e4ade15e87e533bc7f0f2549b89e02109: Bug 1373818 - Allow Adjust campaign ID to behave as OTA distribution. r=rnewman
Michael Kaply <mozilla@kaply.com> - Fri, 16 Jun 2017 16:17:14 -0500 - rev 364444
Push 32042 by archaeopteryx@coole-files.de at Sat, 17 Jun 2017 19:33:32 +0000
Bug 1373818 - Allow Adjust campaign ID to behave as OTA distribution. r=rnewman MozReview-Commit-ID: 8MEQ84PuH7i
b858187d6cb8cd0a6cdffc59f1fd4a7a7777a5ea: Bug 1355677 - Make all Sync network requests promise based. r=kitcambridge,rnewman,tcsc
Mark Hammond <mhammond@skippinet.com.au> - Tue, 11 Apr 2017 23:40:53 +1000 - rev 354273
Push 31694 by kwierso@gmail.com at Sat, 22 Apr 2017 00:06:55 +0000
Bug 1355677 - Make all Sync network requests promise based. r=kitcambridge,rnewman,tcsc MozReview-Commit-ID: JSwAS4Xd1uy
cd021a9b541a7bcc156738319bea0aa73984d11c: Bug 1335198 - Add support for synchronizing bookmark creation date r=rnewman
Grigory Kruglov <gkruglov@mozilla.com> - Tue, 18 Apr 2017 18:04:45 -0400 - rev 353681
Push 31675 by cbook@mozilla.com at Wed, 19 Apr 2017 08:28:05 +0000
Bug 1335198 - Add support for synchronizing bookmark creation date r=rnewman Incoming records might be missing the dateAdded field, and so we perform some pre-processing: - during reconciliation, dateAdded is set to the lowest of (remote lastModified, remote dateAdded, local dateAdded) - during insertion, if dateAdded is missing it is set to lastModified Whenever we modify dateAdded for a record during sync, we also bump its lastModified value. This will trigger an upload of this record, and consequently a re-upload by clients which are able to provide an older dateAdded value. It is possible that this might cause conflicts on other devices, but the expected likelyhood of that happening is low. MozReview-Commit-ID: 3tDeXKSBgrO
8652c254c6e2e45aa10f0a273c908174996159bb: Bug 1354055 - Don't cache wrong result in OSPreferences::ReadSystemLocales on Android. r=jfkthame,rnewman
Zibi Braniecki <gandalf@mozilla.com> - Thu, 06 Apr 2017 13:00:02 +0200 - rev 352851
Push 31652 by kwierso@gmail.com at Thu, 13 Apr 2017 20:03:53 +0000
Bug 1354055 - Don't cache wrong result in OSPreferences::ReadSystemLocales on Android. r=jfkthame,rnewman MozReview-Commit-ID: Li7wUQnC9Gz
5d3bc5f2c41fe7f8ff0c81de23ebbfc7bce7da21: Bug 1354055 - Don't cache wrong result in OSPreferences::ReadSystemLocales on Android. r=rnewman
Zibi Braniecki <gandalf@mozilla.com> - Thu, 06 Apr 2017 13:00:02 +0200 - rev 351719
Push 31618 by cbook@mozilla.com at Fri, 07 Apr 2017 13:06:08 +0000
Bug 1354055 - Don't cache wrong result in OSPreferences::ReadSystemLocales on Android. r=rnewman MozReview-Commit-ID: Li7wUQnC9Gz