This is presently only relevant for XHRMT, so XHRWorker will just report that
everything's a-ok for now.
As noted inline, the permanence of this measure is to be evaluated in
Firefox 60 in bug 1368540.
MozReview-Commit-ID: 6gkTyZO388g
--HG--
extra : rebase_source : d85ec4181c9bd935f8e419d8d450fd17eb5e1837
There are at least four ways XHRMT can error on load.
Let's be specific about it.
MozReview-Commit-ID: EOml2fcd1XD
--HG--
extra : rebase_source : 7f484f04e2dd6f219911408e7af152f85d4776a9
When the last request is removed from the load group, we report telemetry for the default load request. This was done without checking if the request was successful, which may cause us to report telemetry for failed requests as well.
Also, the NullHttpChannel had its timingEnabled attribute set to true, which could lead us to report invalid telemetry
MozReview-Commit-ID: 5w7rd2V17Xd
--HG--
extra : rebase_source : 60785ebc38da8880aa6ded668fed8af81c3d60e9
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
https://bugzilla.mozilla.org/show_bug.cgi?id=1365674
Source-Repo: https://github.com/servo/servo
Source-Revision: 71eb672923365095c45cbd15ee0746eae3908cb6
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : a49f3946d100f3988281242c50faa2d37589da46
This gives us the most actionable piece of information from the perspective of correlating between how the sandbox is configured and behavior we see.
MozReview-Commit-ID: EWWQrDHns1R
--HG--
extra : rebase_source : 5574cae461d0bcab8ac058c032e76436318e5b0e
If the "security.sandbox.content.level" preference is set to a value less than
1, all consumers will automatically treat it as if it were level 1. On Linux and
Nightly builds, setting the sandbox level to 0 is still allowed, for now.
MozReview-Commit-ID: 9QNTCkdbTfm
--HG--
extra : rebase_source : 1a26ffc5b9f80e6df4c37c23f506e907ba44053a
The Flash sandbox (which is the only thing this variable is used for) is stable
at this point, and for testing purposes we still have MOZ_DISABLE_NPAPI_SANDBOX.
MozReview-Commit-ID: 6sxb1tx7oA9
--HG--
extra : rebase_source : d960c5a7afb04b90f098516f955b5fd00628b6a8
- Added new chrome-only webidl methods to be used by browser UI and WebExtensions
- Implemented bitmasked group visibility for VR sessions to enable switching
between chrome and regular content presentations.
- Implemented throttling mechanism to avoid runaway, unthrottled render loops
for VR sessions that are hidden by group visibility bitmasks or due to
lower level platform VR events, such as during the Oculus
"Health and Safety Warning".
- Simplified the PVRManager IPC protocol while extending it to support
VR session groups and later WebVR content performance profiling API's.
- Removed the last WebVR related sync IPC call.
MozReview-Commit-ID: BMEIPyYeEbq
--HG--
extra : rebase_source : 47d3682cad3d913504175b7d4c3e9d992236f097
This means we'll at least see a sensible exception, instead of an NPE when
no anchor is set. That makes it easier to debug cases where no anchor was
set (see e.g. the main commit from this bug).
MozReview-Commit-ID: CzsZaHvnZ6y
--HG--
extra : rebase_source : 2aaf737b49367d9e70fc62a1226e038c79f573e3
There's no way to verify locally the while loop will execute and set the return value, so we get an uninitialized variable warning.
Initialize it at declaration time to failure, relying on the later code to override with success.
Actually, it doesn't matter what we initialize it to, since the while loop will never terminal if GetNextPacket somehow returns success without pushing a new packet onto the sample array. But this silences the warning.
MozReview-Commit-ID: 20rh1OGpR1E
--HG--
extra : rebase_source : 599a6d1bf0d38077bddfcec975e514eb8e5ee67e
Expires in 61 for now until we can show its usefulness.
MozReview-Commit-ID: IpfEnmnuKgr
--HG--
extra : rebase_source : a315e7d9bca161bc014bbc260f9469d762489935
This is presently only relevant for XHRMT, so XHRWorker will just report that
everything's a-ok for now.
As noted inline, the permanence of this measure is to be evaluated in
Firefox 60 in bug 1368540.
MozReview-Commit-ID: 6gkTyZO388g
--HG--
extra : rebase_source : d85ec4181c9bd935f8e419d8d450fd17eb5e1837
There are at least four ways XHRMT can error on load.
Let's be specific about it.
MozReview-Commit-ID: EOml2fcd1XD
--HG--
extra : rebase_source : 7f484f04e2dd6f219911408e7af152f85d4776a9
This just migrates the extra tier-2 linux64-qr test jobs from running on
graphics to running on m-c and try. This is the last step needed for the
graphics team to stop using the graphics branch and switch to using the
regular integration branches.
MozReview-Commit-ID: E0epHQVuXxu
--HG--
extra : rebase_source : f2f542cfad1e3c13a1c9d70d042a72f6e3d74bc3
