Original patch authored by Tim Nguyen (:ntim).
MozReview-Commit-ID: 6qQnRMQXPTH
--HG--
extra : rebase_source : 319d160f3057173359f02adba44bdcc12a68e209
Bug 1092294 introduced a regression in to the code to copy from
the discarded front buffers to the new backbuffers in
SingleTiledContentClient. The aim was to ensure that if locking the
the frontbuffers failed, meaning the region could not be copied, that it
would be painted instead. However due to incorrect logic the
region would both be copied and painted in cases where
there was no onWhite buffers.
To fix this we take both locks (frontLock, and frontOnWhiteLock if
required) up front, so that we either copy both buffers or neither.
MozReview-Commit-ID: 3iepOuweruk
--HG--
extra : rebase_source : 2e2f951c3315f2809191f43a9d5ec4a939c82724
The DBus specification allows passing an empty string as the interface to the
org.freedesktop.DBus.Properties.GetAll call to get all properties, throwing away the namespace
(interface) information.
However, GDBus does not allow this. When NetworkManager moved to using GDBus, Firefox lost the
ability to retrieve access points from NetworkManager.
Since we're only interested in properties from the org.freedesktop.NetworkManager.AccessPoint
interface, name it explicitly. This works with both the old and the new NetworkManager.
MozReview-Commit-ID: Kc5HaYvwfRZ
--HG--
extra : rebase_source : e1550d327e5a4ea05b8d35d98ef7b27c0add709b
Make a copy of the function and specialize it for each message sent.
Avoids the mess of comparing the method name to figure out what to do.
MozReview-Commit-ID: 1KlZyc8Pc9I
--HG--
extra : rebase_source : 1f9c841e42745ecb311c53cd364ffe60b5593258
The bug has something to do with ContainerLayer nesting changes being mishandled:
a new ContainerLayer for the transform is being inserted around the container
layer for the opacity, which has an intermediate surface.
This change makes the outer ContainerLayer permanent so that the dynamic
insertion case is not hit.
MozReview-Commit-ID: lETpsr4YJi
--HG--
extra : rebase_source : 7b82976c7c91328c72b54a931732447d82a3ce6d
The mochitest and reftest selftest tasks are excluded because they also
schedule several builds as dependencies which is likely going to be unexpected
behaviour.
MozReview-Commit-ID: 9eoVJ5qpAMO
--HG--
extra : rebase_source : 469521feff3ba42506ffb54bfe8f009bf9ab9da6
Tasks that have the 'always_target' attribute set will be always be included
in the target_task_graph, regardless of target task filtering.
Furthermore, if they were only added because of this attribute (i.e, the
filters would have excluded the task), then the task will be a candidate for
optimization even if the 'optimize_target_tasks' parameter is False.
MozReview-Commit-ID: 9eoVJ5qpAMO
--HG--
extra : rebase_source : 9635002720d088ca9870649f3143d6293c666610
I've also renamed wikipediaro.xml to wikipedia-ro.xml, since it's the only file without an hyphen.
MozReview-Commit-ID: BXh2t5NzrSt
--HG--
rename : browser/locales/searchplugins/wikipediaro.xml => browser/locales/searchplugins/wikipedia-ro.xml
extra : rebase_source : 40e95cff70c1de7aa26fcc21f3b1f49e383bf3c2
This adds the R.txt files produced by the build -- timestamped, so
they are kept in order -- to the Task Cluster artifacts, for later
comparison.
MozReview-Commit-ID: 3hj6XjFDIE4
--HG--
extra : rebase_source : 04c1bcd2bf62fd193541fa92dd8841db102f6b5a
extra : source : 5a00c3642c972385cd212fe8b15240bce6acef50
As we transition to Gradle (and only Gradle) Fennec builds, we're
turning the Gradle builds (Bg) into non-Gradle builds (Bng). It's not
worth the effort to rename "gradle" to "non-gradle", so this is a
confusing looking patch that turns on GeckoView tests for everything
but Bng (which has kept the "gradle" name).
MozReview-Commit-ID: C1PlsehRwJf
--HG--
extra : rebase_source : f8bfc730ab963833f43d2f19b11027db8e49a06a
extra : source : 50006730ade8dd1a12ec0eec7113f802e6b8497d
This also turns the tier 2 job B(n)g into tier 1, since moz.build is
still tier 1. It also pushes a lot of GeckoView related tasks into
the main builds, since they should run as part of Gradle builds.
This also removes unused tooltool manifests; the jobs that used these
manifests use only toolchain tasks now.
MozReview-Commit-ID: 2GmnJ7joCTT
--HG--
extra : rebase_source : 75cd2dfb51e0e1b510f5e618c2dc881cf5f22bf2
extra : source : 6b95b09d6afbb83ba89c47b237dfce6e15587bbe
We already had a work-around in place for Gradle invocations, but
apparently that wasn't enough for the Maven deployer, which must
launch its own JVM, which doesn't have the correct file encoding on
Linux.
MozReview-Commit-ID: 4z1IEZBmLaz
--HG--
extra : rebase_source : 951bb4c75ecba0d83cb86e728e1164dda99a6a08
extra : source : 6dd2abe095b82ed1a0fed4e687a7bbf3a5e036de
Do not merge this; I'm looking into what it takes to stop running the test-css jobs.
Source-Repo: https://github.com/servo/servo
Source-Revision: 86b9e7d7d604e00cfd7ab63351d3221cd5cf872e
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : d8969e7ae8baab672e88a4f8812872a1f86781b4
As a result of this patch, the hash algorithm used in add-on signature
verification will come from the PKCS#7 signature. If SHA-256 is present, it will
be used. SHA-1 is used as a fallback. Otherwise, the signature is invalid.
This means that, for example, if the PKCS#7 signature only has SHA-1 but there
are SHA-256 hashes in the signature file and/or manifest file, only the SHA-1
hashes in the signature file and manifest file will be used, if they are present
(and verification will fail if they are not present). Similarly, if the PKCS#7
signature has SHA-256, there must be SHA-256 hashes in the signature file and
manifest file (even if SHA-1 is also present in the PKCS#7 signature).
MozReview-Commit-ID: K3OQEpIrnUW
--HG--
extra : rebase_source : 704a2a18e166bfaf3e3d944d13918054bd012000
@gregtatum If you have made changes that would make it hard to land this then I can recreate the patch any time.
I did need to make a few manual changes to get this to work but it is probably a lot easier for me to regenerate the patch than for you to resolve any merge conflicts.
Because the changes are generic and mostly automated you don't need to take too long looking at every detail but you probably want to take a quick look over it. The main thing with a change like this is a green try.
MozReview-Commit-ID: 1p3ts7na1YF
--HG--
extra : rebase_source : 26c96b20960f276e09603482c0a646e9911a3df3
It doesn't matter that this is traversed by the cycle collector when the track is live and playing.
It prevents cycle collection of any number of MediaStreams that contain (thus consume) this track.
MozReview-Commit-ID: GvdLfWDTVQQ
--HG--
extra : rebase_source : 29e65d25bd7cdf03e32ff4aa736b0ff762ebf1c1
Only http://perf.rust-lang.org/ will disable it, in order to be less subject to changes to rustc internal APIs.
Source-Repo: https://github.com/servo/servo
Source-Revision: 7f2ac4c559a2ff99ed7571af646ecee3f33168c3
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 5e7a81c7387f21ed3b09a6740015485f8d813c32
Because the content frame script's clickElement function uses
the old-style despatch technique, all code lines that have the
potential of throwing must be encapsualted in try...catch blocks.
Bug 1400256 accidentally moved them outside this block, and we did
not have any tests for stale elements in web content.
This ensures errors from WebElement.fromJSON and seenEls.get get
returned to the WebDriver service in testing/marionette/driver.js.
MozReview-Commit-ID: 49qjWhXWy69
--HG--
extra : rebase_source : 3e1b639ad253c3fe7eda890de04608a925e256f5
The HTTP status for the "stale element reference" error in WebDriver
should be 404 (Not Found).
MozReview-Commit-ID: CBb7Ds8AEY3
--HG--
extra : rebase_source : 9b4309d43118730e20cb4ba17312a49cc203c58b
wdclient was the name of the old GitHub repository. The actual
Python package name is "webdriver".
MozReview-Commit-ID: FHy3iEB9aAj
--HG--
extra : rebase_source : 1f1a712fef86ab56fd9bc1f3b949e0844e9fae84
Behaviour is controlled through the media.navigator.video.vp9_preferred preference.
MozReview-Commit-ID: J06ArFYNmTk
--HG--
extra : rebase_source : a25bd4783fde0acf8291ee440745a619d3fa7db8
Mention that we need Python3 to build on CentOS
---
<!-- 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
<!-- Either: -->
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because it's only docs
<!-- 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: f946c4f00ce49b1a7ce559ffa2b4ac7f7fe57235
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 9150c53d2a6589d997761fe85ac20d09030391fc
