There's only one interesting case here: the active tab. When rendering the label
of an overflowing active tab into the fadeout mask surface, text rendering must
not use the font smoothing background color for dark vibrancy. Instead, it needs
to use the color of the tab itself for best results.
Alternatively, we could set the font smoothing background color of the active
tab to "transparent", because this text is not on top of a vibrant background.
However, doing so would lose the subpixel AA and would not look as crisp.
MozReview-Commit-ID: 28MKCz1vmb9
This property accepts a color. It's inherited and defaults to transparent.
Its value is respected on macOS when rendering text into transparent pixels.
This property should be used for text that is placed on top of "vibrant"
-moz-appearances, in order to achieve high quality text rendering for such text.
In most cases, the property should be set to a named system color; an upcoming
patch in this patch series will add one such color for each vibrant
-moz-appearance value.
However, in some cases it can also be useful to use a custom color: If text
is rendered into an intermediate surface, for example because a mask is applied
to it, and the background color behind that intermediate surface is known, then
this property can be set to that background color in order to achieve subpixel
AA for the text inside the mask effect. In that case, the font smoothing
background color is respected because text is rendered into transparent pixels
*inside the intermediate surface*. At the moment, the only example of that use
case is the text of the active tab in the state where the text is overflowing.
MozReview-Commit-ID: D98qQnxoFaq
<!-- Please describe your changes on the following line: -->
These are the necessary servo changes for https://bugzilla.mozilla.org/show_bug.cgi?id=1387594 .
I'm also re-importing the generated Gecko bindings from my object directory:
- servo/components/style/gecko/generated/structs_debug.rs
- servo/components/style/gecko/generated/structs_release.rs
But the number of changes to those files surprises me.
---
<!-- 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
- [X] These changes do not require tests because they're tested by compiling mozilla-central once the patches from https://bugzilla.mozilla.org/show_bug.cgi?id=1387594 land - without this patch, Firefox won't compile.
<!-- 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: 28b1c3818f81f593e691ded1109cfaab829825ae
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 2934de139097f1426e76fe4775a852f67fc9abbe
I don't scale the pin size/margins based on the dynamic tile size. This could
mean we get into situations where the pin crowds out the top site tile but I
don't know if this would happen in practice.
MozReview-Commit-ID: Ct8EP3dPr6N
--HG--
extra : rebase_source : b527cff1faf5a565d1cf309ce3063b8d23553150
The MozillaBuildBootstrapper specific rust install code in not needed as
mozbase already includes genertic code to achieve the same outcome. The
mozilla-build specific code also leads to issues where it tries to add already
existing targets and fails the bootstrap. This changeset removes the
mozilla-build specific step.
MozReview-Commit-ID: G0BqKZrF40A
--HG--
extra : rebase_source : 60e9638afff744c937a9665d6fd5830187835ea4
Bloaty says this shaves off another 20kb from style::properties-based functions. The more limited Debug implementations enable sharing the property name strings between more functions, which saves on code size in the end.
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
Source-Repo: https://github.com/servo/servo
Source-Revision: ddf7ad4814a956ea866cd76da6ccda6b33af438b
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 29f7df3b4bbbad15ccfc849cc7638c3ca05846c2
The mechanics implemented here involve listening for extension updates that
require new permissions, notifying the user with icons attached to the
top level Add-ons menu and to the individual item in about:addons, and
then showing the permissions dialog when the user asks to update.
The basic plumbing is mostly in ExtensionPermissions.js, this also
required a fair amount of change to aboutAddons to accomodate new UI
elements, and to handle updates gracefully.
MozReview-Commit-ID: Jkgc3OVYtnc
--HG--
extra : rebase_source : 5df3e12df8c422285fbc25c459dc420b395fa824
GeckoMenu always create view from MenuItemDefault. Now lets adding a
new type for MenuItem which will display a Drawable in right side.
MozReview-Commit-ID: F7zVDze0RaP
--HG--
extra : rebase_source : c913ef385aaf99c948edb252136c2b7f39526730
extra : intermediate-source : 2c098c90a58faee8b928eb1cec5cb841897c57e2
extra : source : b107e0b122445393a804116d763e2f13da6b6036
More plumbing in preparation for isolating the UA stuff.
Source-Repo: https://github.com/servo/servo
Source-Revision: 2cbd27c83a6974f6d00ccd2873ff1914c3af0614
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : bff6f79a1b2250b47d33fd04b2a374591de176d6
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 : 02ad1f3f778589ce05529f22d7d7bee03e5970e5