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 : 3890c6ebff512c94ee51539048cbb9ebd9aef360
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 : cd5a853c46a5cd334504b339bef8df30a3cabe51
<!-- Please describe your changes on the following line: -->
See https://github.com/servo/servo/issues/11921
After fixing problematic dependencies this is the last step to support armv7-linux-androideabi target on Android:
- Updates skia dependency to fix a linker error. See https://github.com/servo/skia/pull/136
- Fixes specifying android targets on `./mach package` and `./mach install` steps:
-`./mach package --release --target=arm-linux-androideabi`
-`./mach package --release --target=armv7-linux-androideabi`
-`./mach package --release --target=aarch64-linux-android`
- Make `armv7-linux-androideabi`default when `--android` param is used in build, package or install commands
---
<!-- 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#11921 (github issue number if applicable).
<!-- Either: -->
- [x] There are tests for these changes OR
- [ ] These changes do not require tests because _____
<!-- 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: a694f70acf2f011da816a24716d6501ab153c64e
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : aac3cdcf833b6cd64b5f81d27ae213d7272fe08d
To take advantage of nikomatsakis/rayon#348.
<!-- Please describe your changes on the following line: -->
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [ ] `./mach build -d` does not report any errors
- [ ] `./mach test-tidy` does not report any errors
- [ ] These changes fix #__ (github issue number if applicable).
<!-- Either: -->
- [ ] There are tests for these changes OR
- [ ] These changes do not require tests because _____
<!-- 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: 3337fccd991fcf9e935b1ada55621be474ffb6e6
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : ac84159cdc8e6d65c87916de46594de7c0490318
Expires in 61 for now until we can show its usefulness.
MozReview-Commit-ID: IpfEnmnuKgr
--HG--
extra : rebase_source : b5b45cda2f90aee6a52fccc073d4c4ff5e381c5e
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
