Adding tests that would have shown the issue fixed in Bug 1405940.
If the answer during a renegotiation has modified ICE credentials,
it should cause an error. These tests check for that error.
MozReview-Commit-ID: 9u8GGpslDdK
--HG--
extra : rebase_source : 6b204cefa96e95abd61d9a57ddd643dd81a41254
Instead of a general socket timeout failure indicate that no hello
data has been received through the socket right after the call to
connect().
MozReview-Commit-ID: EPNiCLNyFFH
--HG--
extra : rebase_source : 05c45e99b3250f847a5c8120f23ecc9dd154212c
The getter for socket_timeout should always return the current socket
timeout from the socket instance first, and only fallback to the
private property if no socket instance exists.
This ensures that all methods will always operate on the current
socket timeout value.
Also using a timeout of 2s for receiving the hello string might be too
less for slow running builds. To prevent intermittent failures for
start_session, a good value might be 60s.
MozReview-Commit-ID: HywjFfClrRr
--HG--
extra : rebase_source : 4207e46c99445ddf7e0c4b653c865e76eb9a9c23
The make backend is the only thing that is aware of PROGILE_GEN and
PROFILE_USE, so we move these ldflags to their own variable while
converting the remainder of ldflags to mozbuild.
MozReview-Commit-ID: GwbPD6Q4Oyn
--HG--
extra : rebase_source : 3c90def9ee8cd949dd135ba8fa9b192f114f6727
These flags are only relevant on OS X, and will not be necessary soon, so this
commit moves them to a separate variable while we move the remainder of the
ldflags to mozbuild.
MozReview-Commit-ID: 1NDgz3HIYpT
--HG--
extra : rebase_source : 6e9b5f5a5be5ff916db89a0b73896b9058eb040e
All of our .proto are optimized for LITE_RUNTIME so we can use
libprotobuf-lite instead of the full libprotobuf.
devtools does need something that's not part of libprotobuf-lite
(gzip streams) and so we add that to our builds.
MozReview-Commit-ID: BW8WnTC6pv
--HG--
extra : rebase_source : ad5f3832c29f1337ecfd4d7d88d09563c1794bca
This is essentially a no-op but it does silence the following warning
whenever the *.pb.* files are re-generated:
[libprotobuf WARNING google/protobuf/compiler/parser.cc:546] No syntax specified for the proto file: LayerScopePacket.proto. Please use 'syntax = "proto2";' or 'syntax = "proto3";' to specify a syntax version. (Defaulted to proto2 syntax.)
MozReview-Commit-ID: 6L1TXHLcjsj
--HG--
extra : rebase_source : c88211414242c921eeefec27476c4a52e6c0974a
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
