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
--HG--
extra : rebase_source : 110224b2db85a383635db933ec6c19b21af886e7
We currently allow the content process to shutdown the IPDL objects on
behalf the parent, and we wait for all of these instances to be freed
before we complete shutdown. This is undesirable because it requires the
parent to trust the child rather than the other way around; the child
can hold shutdown hostage by simply not releasing its instances. The
child should already support the parent closing its graphics IPDL
objects because the GPU process itself can die abruptly and be restored
at a later time.
This is a typo bug of Bug 1053779 Part 2. ConvertListType might return NS_OK
even if ReplaceContainer doesn't return valid value.
So, to clean up code, we should return Element instead of nsresult since out
parameter of this function is Element only.
MozReview-Commit-ID: 44UHETzcdGy
--HG--
extra : rebase_source : ab76486505cb4e7caea3fb99e11fccd606878f02
See commits for details.
Source-Repo: https://github.com/servo/servo
Source-Revision: 4450bbdb0c44637a3caa05bd14a6e2b9d867a74e
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : f97eac4495b2898422b8648f9dc4a3c15ddc9e76
Apparently, if you don't have whitespace above the bulleted list, it won't
format as a list.
MozReview-Commit-ID: LiLpSNScBxR
--HG--
extra : rebase_source : b3ec064a98a531aab5f38d7f4b3f338499010e97
The top sites menu button was removed in a previous iteration and long-click is
used to access the context menu now.
MozReview-Commit-ID: KzTg4Py8o8W
--HG--
extra : rebase_source : cc145006028b301b989ded16d15d3b12317be473
In the bug, we decided that it was okay to document this case because:
1) we didn't know the specific questions we were trying to answer
2) We were facing the 57 deadline
The alternative would be to change the behavior to perhaps the more intuitive
behavior where suggested sites will always be marked as "suggested" clicks but
note that there may be privacy concerns with that (in that there are a limited
number of suggested sites so we'd know the frequency that unique users might
visit the suggested sites).
MozReview-Commit-ID: GxQZzwoZ1nQ
--HG--
extra : rebase_source : 9c6697ef478a5ba08e1503d8360d1214419266fd
ThreadLocalKeyStorage uses Thread Local APIs that are declared in
processthreadsapi.h (although it's more common to just include
windows.h). If a caller wants to use this class, it is their
responsibility to include an appropriate header before including
ThreadLocal.h
MozReview-Commit-ID: GO5dHKVWpZO
--HG--
extra : rebase_source : ff8d6cda1eed7bd9d54745c869b4e47a895b605a
This fixes Single Locale Repacks for Fennec 57.0 betas.
This broke because our merge scripts rewrote l10n-central to mozilla-beta expecting the l10n repo to be called 'mozilla-beta', which is no longer true with cross-channel l10n. When we patched the configs we didn't see a 'mozilla-beta' entry here, butmissed that the merge-day scripts change it on us.
MozReview-Commit-ID: F7BJzpZg0Xj
--HG--
extra : source : cc652dcb13dba40ae3f263ae89ce3e610a34165f
extra : amend_source : 9fa72e4b2a662a6a63ddfc59dbacf7f03e57dd67