This vector was there to pre-acquire locks and give all declarations the same lifetime (which is necessary for custom properties cascading).
https://github.com/servo/servo/pull/16014 introduce a guard to a shared pre-acquired lock, making this vector unnecessary.
<!-- 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: -->
- [x] `./mach build -d` does not report any errors
- [x] `./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: a5a5abd9f4c8a0a9f0b99f8cefcc12151e537d3e
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 561be88a6d42949eaa888ac1293badd2279db565
The shared preferences keys used for storing/retrieving the activity list data are constants, so it is a bit disconcerting to see them named like normal member variables.
MozReview-Commit-ID: GivVloU0pFv
--HG--
extra : rebase_source : e26bcabd1cdf549e8a0ee54f0e6333c76484ca24
Meiryo has same glyph for both normal style and italic/oblique style. Therefore, if we will use it as default Japanese font, italic/oblique style won't be used in Japanese text. It's too bad for <em>, <i> and backward compatibility with MS PGothic.
This patch makes gfxDWriteFontList and gfxGDIFontList ignore italic style face(s) of Meiryo at creating Meiryo's font face list.
Note that in GDI mode, font names are localized. Therefore, we need to compare with both English name and Japanese name. However, in DirectWrite mode, face names are not localized. Therefore, it's enough to compare only with English face names.
MozReview-Commit-ID: 60tFxB0jcd
--HG--
extra : rebase_source : 45eb61403f97cd765de1b81c290c29632d8174e5
Fix#16165.
Also, it turns out that the CSSFontFaceRule IDL specified in the css-fonts spec is not web-compatible. Instead browsers implement a .style attribute like in CSSStyleRule: https://github.com/w3c/csswg-drafts/issues/825
This in turn requires preserving data about which descriptors were set or not (distinguishing unset from set to a value that happens to be the initial value), so this commit also makes every field `Option<_>`.
Source-Repo: https://github.com/servo/servo
Source-Revision: fac0d17fd6edf996876d6e6379e48ef4f9cb43d6
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 53db8dcde3e41e82100219b37ef20b2bc76b9f6b
Add two new prefs (widget.chrome.allow-gtk-dark-theme and widget.content.allow-gtk-dark-theme) to enable dark
themes in chrome and content when e10s is enabled.
When e10s is disabled then widget.chrome.allow-gtk-dark-theme controls both chrome and web content settings.
That may be a bit confusing but it's going to be here for two releases only (Firefox 57 is going to have e10s enabled by default) and actually matches recent state when only one ENV pref is used for both chrome and web content.
The existing MOZ_ALLOW_GTK_DARK_THEME environment variable is still considered, but, now is like widget.chrome.allow-gtk-dark-theme, no longer affecting separate content processes.
MozReview-Commit-ID: CCwriA66CNj
--HG--
extra : rebase_source : 93e9a504af3e7570f82ddaf0890e374fe939e919
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.
<!-- Please describe your changes on the following line: -->
See https://github.com/emilio/rust-offscreen-rendering-context/pull/94 and https://github.com/servo/glutin/pull/121
---
<!-- 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
- [ ] These changes fix #__ (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: f659d43bd403e4ac1305990ba704f23b4a6cd5e6
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 76e38ca77cc9227bfaa6f30cc6445cdfcbacf29c
Errors thrown are printed to console and there is no point in having a
custom catch to print it.
This also makes it possible to start Marionette programmatically without
worrying about disappearing errors.
MozReview-Commit-ID: GGhyCyYqJg
--HG--
extra : rebase_source : 4e38a2e10b259bb8b9e3ade09c1f7030cb2e2220
Port 666 is in the protected port range and can not normally be bound
to unless the process is running with sudo permissions.
We can instead bind to port 0, which will give us a system-defined port
in the epemeral range.
MozReview-Commit-ID: Ld6BDMhtbck
--HG--
extra : rebase_source : 681fd6c6fb382d629aa1b39ca9079f45deb0f059
This is a follow-up to address a fallout caused by bug 1344748 whereby
deprecated preferences relevant to Marionette are no longer being
picked up. This is preventing trace logs from being emitted in CI.
The old logic related to falling back to a deprecated preference is
faulty in that it the preferred, new preference always exists through
the power of testing/marionette/prefs.js. This patch introduces a new
helper method getPref that first looks at whether the preferred pref
is set, and only falls back to the deprecated if it isn't set and the
deprecation preference exists.
MozReview-Commit-ID: 8DeawLAELyK
--HG--
extra : rebase_source : 42ecec05ff84b353d0eda81891849886900fabb7
The Marionette component ships in Firefox, but is not enabled by default.
We want to facilitate activating Marionette at runtime by flipping
the marionette.enabled preference, and showing the Marionette related
preferences in about:config helps discoverability.
It is also useful to rely on the preferences' default values so that
they do not have to be hardcoded in the component.
When Marionette is enabled by setting marionette.enabled to true, a set of
recommended automation preferences found in testing/marionette/server.js
are set if the user has not overriden/user-defined one of them and
marionette.prefs.recommended is true (default). When Marionette is
stopped, the altered preferences are reset.
MozReview-Commit-ID: 3HLnEI0TEBB
--HG--
extra : rebase_source : 00b22e2b63cf2f5183c49bdc84bcc172b8a4c3a1
Files appended to JS_PREFERENCE_FILES are moved into the
objdir/dist/bin/defaults/pref directory, shared with default global
preferences from other parts of Gecko.
To ensure Marionette's preference file ends up in this directory with
a sensible name, we put it in testing/marionette/prefs/marionette.js so
that it ends up in the objdir as dist/bin/defaults/pref/marionette.js.
MozReview-Commit-ID: 9YJ7vysDjSJ
--HG--
rename : testing/marionette/prefs.js => testing/marionette/prefs/marionette.js
extra : rebase_source : d5bf0abf80d20086945d51e05f3e5115880fdc20
Simon Sapin
Jan Henning
Masayuki Nakano
Carsten "Tomcat" Book
Emilio Cobos Álvarez
k88hudson
Martin Stransky
Daniel Stenberg
Benjamin Bouvier
Eric Rahm
Eugen Sawin
Dão Gottwald
Paul Adenot
Kevin Jones
Sebastian Hengst
Tim Taubert
Ehsan Akhgari
Timothy Nikkel
Peter Van der Beken
Henri Sivonen
Jim Porter
Imanol Fernandez
Wes Kocher
Andreas Tolfsen