rather than casting them to `u8` then do inexhaustive match.
I don't see why we couldn't do this.
Source-Repo: https://github.com/servo/servo
Source-Revision: 9dd05136474ff361651f9d5c7c4b114f84736243
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : dd4e9497e822911e3a174a4337189a3bcbf30fcb
Using TYPE_INTERNAL_STYLESHEET here is incorrect because we're not
necessarily fetching style sheets -- just some text. This may run
afoul of X-Content-Type-Options.
MozReview-Commit-ID: HB7YfWwq6CI
--HG--
extra : rebase_source : 6c69fd4bd075d9d53026798d731edc3423f4474d
When saving an original style sheet, arrange not to reload the text
from the OriginalSourceActor afterward. The actor will serve stale
text, but the editor knows better already.
MozReview-Commit-ID: BcMaSSB1uhA
--HG--
extra : rebase_source : 5023f67d17d1702dcd4b1c8fb13562e08d115b18
Currently tabs.onActivated (for the tab that becomes active after a tab is removed) fires before
tabs.onRemoved (for the tab that was removed). This is neither the order in which Chrome fires
these events, nor is it the order in which the internal TabSelect and TabClose happen in Firefox.
This bug fixes this so tabs.onActivated fires *after* tabs.onRemoved.
Note that this does introduce an issue in in-process mode, where window.close() will not
trigger a tabs.onRemoved event for the window, but Kris says "Meh" about that.
MozReview-Commit-ID: CrFR3jqL2u5
--HG--
extra : rebase_source : 5cc3d2a138bf812d13779e8ca1188b89ddbcdcc1
This avoids doing wasted work, at least in the recascade case, and pretty likely
in the other as well.
Source-Repo: https://github.com/servo/servo
Source-Revision: 988728e9d5c66e6bf2f9e0e03a50a814d0e1f2ab
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 68555686bb062ce696e70ffcbdbd07fe6960a5da
Rule cache
<!-- Please describe your changes on the following line: -->
This adds a TLS-based cache reset styles structs keyed off rule nodes. Reviewed in https://bugzilla.mozilla.org/show_bug.cgi?id=1367635 by me and Emilio.
---
<!-- 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: 874cb0d9df44e62a78d427f22f234a13227d07f8
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 94d8df7014ae82e639bb93f209eea4605f7d8964
In Android, "privacy.trackingprotection.state" is not a "real" pref name, but it's used in the setting menu and browser.js.
"privacy.trackingprotection.state" and "privacy.trackingprotection.pbmode.enabled"(deleted) in Android is init in Helper.getPrefs and passed to browser.js when changed.
The real pref for tacking protection are two Gecko pref in browser.js. They are:
"privacy.trackingprotection.pbmode.enabled"
"privacy.trackingprotection.enabled"
All prefs in Android are delegated to them. The Android setting UI simply reflects the single source of truth (Gecko pref).
That's the reason why the two Android perfs use android:persistent="false"
MozReview-Commit-ID: 5ehBhtNM2Tx
--HG--
extra : rebase_source : ef38ab9ac20408cbe0a0ad9ccd12c097e2ee6861
