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

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

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

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" Firefox Account's are 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

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

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

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

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

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

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

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: in6GGep14F

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Bug 1408710 - Serialize RecordsChannel r=rnewman This patch does two things: - serializes flow of records through the RecordsChannel - simplifies the batching logic Main goal is to speed up the flow of records without regressing memory consumption. This patch explicitly does not address the delegated nature of fetch and store, although it is not largely irrelevant. MozReview-Commit-ID: J2afmgr1Td1

Bug 1408710 - Serialize RecordsChannel r=rnewman This patch does two things: - serializes flow of records through the RecordsChannel - simplifies the batching logic Main goal is to speed up the flow of records without regressing memory consumption. This patch explicitly does not address the delegated nature of fetch and store, although it is not largely irrelevant. MozReview-Commit-ID: J2afmgr1Td1

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

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

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

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

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

Bug 1431260 - Switch Android code to read multilocale.txt. r=rnewman MozReview-Commit-ID: 6S4VaAvDako

Bug 1431260 - Switch Android code to read multilocale.txt. r?rnewman MozReview-Commit-ID: 6S4VaAvDako

Bug 1431260 - Switch Android code to read multilocale.txt. r?rnewman MozReview-Commit-ID: 6S4VaAvDako

Bug 1431260 - Switch Android code to read multilocale.txt. r?rnewman MozReview-Commit-ID: 6S4VaAvDako

Bug 1431260 - Switch Android code to read multilocale.txt. r?rnewman MozReview-Commit-ID: 6S4VaAvDako

Bug 1431260 - Switch Android code to read multilocale.txt. r?rnewman MozReview-Commit-ID: 6S4VaAvDako

Bug 1431260 - Switch Android code to read multilocale.txt. r?rnewman MozReview-Commit-ID: 6S4VaAvDako

Bug 1431260 - Switch Android code to read multilocale.txt. r?rnewman MozReview-Commit-ID: 6S4VaAvDako

Bug 1431260 - Switch Android code to read multilocale.txt. r?rnewman MozReview-Commit-ID: 6S4VaAvDako

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

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

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

Bug 1305563 - Add a bookmark mirror and two-way merger for synced bookmarks. r?markh,rnewman,tcsc,mak 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