In bug 1406856 the failedCertChain property of nsITransportSecurityInfo was
changed to hold the built certificate chain out parameter from the call to
CertVerifier::VerifySSLServerCert. However, this was incorrect for two reasons:
a) failedCertChain is supposed to be the peer cert chain delivered by the server
in the TLS handshake and
b) if VerifySSLServerCert returns a failing result, the out parameter is not
guaranteed to hold any meaningful information, and must not be used.
This patch sets failedCertChain to the appropriate value.
MozReview-Commit-ID: BEXs5XH9SpK
--HG--
extra : rebase_source : f50ea725ccb67408ab1ce33cd76d3956ebd10e29
Pushing to the remote exposes sensitive data in the logs of the job. The old token has been revoked as a consequence.
Source-Repo: https://github.com/servo/servo
Source-Revision: b5e5a99cb773a8df6f8f2ee40d8ae42ae46bab92
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 00ff72385507b652e6c2103a87f321a30f86be63
Also export paymentRequest so it's accessible to debugging.js in the next commit
MozReview-Commit-ID: 9w6zaQZanfJ
--HG--
extra : rebase_source : f1bd763033846833e6d93841f98e06c6f7260d38
The properties limit was being exceeded because the telemetry code itself
added a num_slices property. The GC already adds a slices property
(containing the number of slices) so I've fixed the issue by removing the
creation of the num_slices property, which will stop this limit from being
exceeded.
--HG--
extra : rebase_source : dd5c54fe88f4511b4dffa6e52b7b4d8709886f42
* * *
Bug 1434429 - Followup bustage fix (?) for gcc (and maybe other?) compiler bustage. Worked in recent clang... r=boogstage in a CLOSED TREE
--HG--
extra : rebase_source : 68ecbc2d8134194def98326ef9bcbdb4718189a4
In general, there is no simple mapping between apk name (geckoview_example.apk) and
package name (org.mozilla.geckoview_example). With bug 1434411, it will be relatively
easy to add or modify tasks to use a geckoview apk in taskcluster tests. At the
mozharness level, scripts are expected to expand mozharness configurations containing
"%(app)" into package names. For Firefox, android_emulator_unittest extracts and
reads package_name.txt, but there is no such file in the geckoview apk. In future
we might add package_name.txt to the geckoview apk, or possibly use a tool like aapt,
but for our immediate needs this simple hack does the job: If "geckoview" is in
the apk name, assume we are installing org.mozilla.geckoview_example.
PeerConnectionImpl defines two versions of various fallible methods: a version
taking an ErrorResult argument, and a version returning nsresult. The methods
were not marked fallible in the webidl, so the bindings called the
nsresult-returning version, but ignored the returned value. As a result,
failures got swallowed instead of being propagated out.
The changes here annotate the relevant parts of the webidl as throwing, and
convert non-fallible methods to returning void to make infallibility clearer.
MozReview-Commit-ID: JU9NzmEf8FV
I left some IgnoredErrorResults for now where people warn on failure. We could
consider adding a WarnOnError() thing or something.
MozReview-Commit-ID: L5ttZ9CGKg0
