To make sure the last (unknown) entry is always -1.
Also, nsDirIndexParser::ParseFormat() must return OK even when bailing
out early to not cause subsequent problems.
--HG--
extra : rebase_source : fea969159e73ff2f438dd42559e87ad8eb183acf
This switches over layout's usage of PLArena to ArenaAllocator. This allows
us to build more files in unified sources and gets rid of various CONST masks.
MozReview-Commit-ID: Aaf3Dl2kaoz
Docker-worker's `command` field is actually not required, as it will run a
docker image's default command when command is not specified.
MozReview-Commit-ID: I3vBHeixlxW
--HG--
extra : rebase_source : a5d02c3131dd6ffb307c37e827d58aa8686ccaf8
e10s-based <select> dropdowns behave differently from the old, non-e10s
version. Most notably, their .value isn't updated until the dropdown is closed
and the change confirmed (e.g. by hitting Enter). Since this test originally
hit ctrl+space at the end of each test, this would open up the dropdown and
effectively trigger the different behavior. Now, the test only hits ctrl+space
for <select multiple> elements.
MozReview-Commit-ID: G3toKNdRgC8
--HG--
rename : layout/forms/test/test_bug961363.html => layout/forms/test/test_select_key_navigation_bug961363.html
extra : rebase_source : 26e581ae7f72a1c993915de1bcf2a325d2d86583
<!-- Please describe your changes on the following line: -->
This is a PR for https://bugzilla.mozilla.org/show_bug.cgi?id=1352771
---
<!-- 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: -->
- [X] These changes do not require tests because it's for stylo
<!-- 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: eb1865070a8324016c369104afa159fdec345bea
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 9fb3d024c4874d9492efecdea37da7f88d9c0b50
When the profiler is running in privacy mode, we don't want to include dynamic
strings from PROFILER_LABEL_DYNAMIC to end up in the profile.
Rather than checking this every time we enter a scope marked with
PROFILER_LABEL_DYNAMIC, with this patch we will push the dynamic string into
the pseudo stack entry regardless, and then check the privacy mode during
sampling and ignore the dynamic string as necessary.
This way we can avoid taking the profiler state lock in PROFILER_LABEL_DYNAMIC
and also save a branch.
MozReview-Commit-ID: 5dXrtMuFJ5r
--HG--
extra : rebase_source : 1c2057e7ced332d9001137b5b280feab77a712e5
Since we cannot call .First() on it and since it clearly contains
nothing to show anyway!
--HG--
extra : source : ecd714c21c5bd643875d85101dccaaeff18bd350
extra : amend_source : 22307168ed9289c36dade3f33a7c3ded93b5612c
These files were being excluding because we thought they used plarena.h, but it
turns out they did not. A few tweaks needed to be made to clarify whether we
wanted to use mozilla::UniquePtr or js::UniquePtr.
MozReview-Commit-ID: 1su5dO3rR0T
This updates the unifed sources for a few netwerk build files. In some cases
files were excluded because we thought they used plarena.h, but that turned
to be false.
A few files needed to be updated to add missing imports/exports due to shifting
of compilation units.
MozReview-Commit-ID: 4mh8VApFoe1
PrivacyLevel checks currently allow to disable storing secure cookies and any
cookies belonging to an HTTPS host, or completely disable storing cookies. We
call PrivacyLevel.canSave() for every host found in the shistory of a given
window's tabs. We then call it again for every cookie when retrieving all
cookies stored for a given host.
The two different privacy checks exist because in the past an HTTP site could
send a secure cookie too. Since Firefox 52 this isn’t possible anymore, only
HTTPS sites can send secure cookies. So as soon as nsICookie.isSecure=true
we know the site was loaded over TLS.
That means there are the following scenarios:
[PRIVACY_LEVEL=NONE] (default)
We store all cookies.
[PRIVACY_LEVEL=FULL]
We store no cookies at all.
[PRIVACY_LEVEL=ENCRYPTED]
HTTP site sends cookie: Store.
HTTP site sends secure cookie: Can't happen since Fx52
HTTPS site sends cookie: Store. The site is HTTPS but we should store the
cookie anyway because the "Secure" directive is missing. That means the
site wants us to send it for HTTP requests too.
HTTPS site sends secure cookie: Don't store.
This allows us to simplify the code and remove the per-host PrivacyLevel
checks. Checking nsICookie.isSecure is enough to tell whether we want
to keep a cookie or not.