This patch implements the `::target-text` pseudo element.
Similarly to the Custom Highlight API, this is done implementing
a new Selection type.
Differential Revision: https://phabricator.services.mozilla.com/D195687
This patch implements the `::target-text` pseudo element.
Similarly to the Custom Highlight API, this is done implementing
a new Selection type.
Differential Revision: https://phabricator.services.mozilla.com/D195687
This patch implements the `::target-text` pseudo element.
Similarly to the Custom Highlight API, this is done implementing
a new Selection type.
Differential Revision: https://phabricator.services.mozilla.com/D195687
This patch implements the `::target-text` pseudo element.
Similarly to the Custom Highlight API, this is done implementing
a new Selection type.
Differential Revision: https://phabricator.services.mozilla.com/D195687
This patch doesn't change behavior. It's just replacing a magic number `5` with
a constant whose value is automatically inferred based on the enum that it's
defined within. (The enum's other values are explicitly 0-based so that they
can serve as array indices, so it's natural to define a final sentinel
enum-value to represent the count of valid indices.)
Differential Revision: https://phabricator.services.mozilla.com/D197755
This patch doesn't change behavior.
The APIs that I'm changing here are all indexing into an array that only has 5
entries; it's a bit odd to be using a signed array-index for this, particularly
since the indices all originate from GetUnderlineStyleIndexForSelectionType()
which explicitly returns values 0 through 4 (as enum values).
I suspect we were using signed index because we were using an enum to represent
the values, which was signed-by-default. Let's just explicitly declare the
enum to use an unsigned underlying representation, and then change its
downstream integer variables/params to be unsigned as well.
Conveniently, this lets us simplify the assertions about the index being
in-range, since unsigned values are >=0 by definition.
Differential Revision: https://phabricator.services.mozilla.com/D197754
This patch doesn't change behavior.
We have a gecko convention that pointer-returning getters will only have "Get"
in the name if they might return nullptr (and the caller needs to check for
this).
This particular API doesn't ever return null, so it shouldn't have "Get" in its
name.
Differential Revision: https://phabricator.services.mozilla.com/D197753
This patch doesn't change behavior. It just replaces an "is-this-initialized"
bool with our more declarative Maybe<> struct which is uninitialized-by-default
(and brings along debug-build checks to ensure we don't use before
initializing).
Differential Revision: https://phabricator.services.mozilla.com/D197752
This comes back all the way to bug 654411. This doesn't work great with
semi-transparent backgrounds (like the one on that theme) because we
don't bother computing the "real" background (we can't really, since
it's partially a background image).
I don't think text rendering quality should be worse with alpha text
nowadays. I guess we could preserve it with some effort for opaque
mFrameBackgroundColor values (propagating whether it was really opaque
or not), but let's not do it unless we really need to.
Differential Revision: https://phabricator.services.mozilla.com/D185512
Due to the prioritization rules for custom highlights, it is not feasible to rely on cascading.
Instead, highlights need to be stacked by their priority (and order of insertion).
Text and background color of the highest-prioritized highlight which defines that property should be used.
Since highlights are implemented as special `Selection`s, the algorithm that determines the prevailing selection for a text frame needed to be adapted to instead return a list of selections.
Differential Revision: https://phabricator.services.mozilla.com/D181143
This simplifies a tiny bit our bindings in some places, and complicates
it in others, but over all I think it's better.
It requires a bit more manual code in the rust side to drop and cast the
relevant pointers (which was done implicitly before), but it's a lot
less magic than it used to be, and that's all autogenerated so consumers
don't need to care about it.
The set up is still not ideal. I don't like that we rely on destructors
running in both sides of the FFI boundary, but that's for another day.
This is the last usage of RawOffsetArc, so remove that. We now support
proper Arc<> in structs (GridTemplateAreas uses it), so I don't think
we'll need it any time soon.
Differential Revision: https://phabricator.services.mozilla.com/D177905
Jan-Niklas Jaeschke