<!-- Please describe your changes on the following line: -->
https://bugzilla.mozilla.org/show_bug.cgi?id=1400459
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix https://bugzilla.mozilla.org/show_bug.cgi?id=1400459
<!-- Either: -->
- [ ] There are tests for these changes OR
- [X] These changes do not require tests because tested on the Gecko side.
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: 54f8a131ea50fe8b0480d9f146acc97e13bc45d6
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 490a18d56715a458cad9f0ee341ca798a1b1dc2d
As noted in my code-comment here: Gecko's CSS parser incorrectly accepts this
CSS -- wherease Stylo correctly rejects it. Rather than trying to fix this in
Gecko, I'm just adding it in such a way that our expectation changes depending
on which CSS engine we're using. This lets us regression-test this in our
now-default stylo configuration, and still detect accidental/unexpected
behavior-changes in Gecko.
MozReview-Commit-ID: whLGIrh7TQ
--HG--
extra : rebase_source : fd80ea3ca3ef0a39d1ceae36db11ec2a9e281e25
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
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
xpcshell can sometimes create and then almost immediately kill the GPU process. This can
cause the connection state of GPUParent's message channel to be in error or closed
when it attempts to send its build ID. In this case we should ignore the request
because the process will soon close.
MozReview-Commit-ID: EAupU844iFo
--HG--
extra : histedit_source : df05a01df5ad095b4e3c91e0e038d4e145da5f9d
