The only use of this type used to be carrying around an owning reference
to a thread-local. However, since bug 1577439 we're leaking the
allocation intentionally, so we can simplify the code to explicitly use
`Box::leak()`, which in turn removes all unsafe usage around these, and
allows us to drop the owning_ref dependency altogether.
Differential Revision: https://phabricator.services.mozilla.com/D209912
The only use of this type used to be carrying around an owning reference
to a thread-local. However, since bug 1577439 we're leaking the
allocation intentionally, so we can simplify the code to explicitly use
`Box::leak()`, which in turn removes all unsafe usage around these, and
allows us to drop the owning_ref dependency altogether.
Differential Revision: https://phabricator.services.mozilla.com/D209912
This doesn't yet expose it to a11y but that will be done by the a11y
folks, since this blocks some of the a11y interop test-cases.
Modify the tests to not hit the network, and make -moz-alt-content not
exposed to content (we only need it for UA stylesheets).
Differential Revision: https://phabricator.services.mozilla.com/D209690
This is the logical continuation of bug 1121792. This improves on the
existing support by totally removing all the manual nsTArray bindings,
which have always been a bit clumsy.
This is a prerequisite for bug 1281158 because I want to use ThinVec to
avoid a few extra heap allocations in the computed values of the Content
property.
Differential Revision: https://phabricator.services.mozilla.com/D209689
Most of this code is already dead. The native appearance on macOS
doesn't work on dark mode, and on Windows and Linux we are already
overriding it.
Add a first-column tree property to be able to align the inner borders
on macOS properly.
Differential Revision: https://phabricator.services.mozilla.com/D206526
We keep track of whether there was an origin color available so that we
can serialize hsl and hwb colors in modern srgb syntax.
Differential Revision: https://phabricator.services.mozilla.com/D209490
Add one extra branch if we have before-change style but its display
is none, and the new style is not display:none. Also, we add an extra
subtest if we use the container query to change the display property.
Differential Revision: https://phabricator.services.mozilla.com/D208572
Now we use the starting style if we have, to replace the before-change
style. This includes a minor refactoring of the handling of transitions
because it becomes a little bit complicated.
Differential Revision: https://phabricator.services.mozilla.com/D208571
Per spec, we define starting style for an element as the after-change style
with @starting-style rules applied in addition.
If an element does not have a before-change style for a given style change
event, the starting style is used instead of the before-change style to
compare with the after-change style to start transitions.
The basic idea in this patch is:
1. We add a flag to indicate if this element may have starting style. We
set this flag during its full matching, and store this flag in the
element data.
2. So during process animations, we check this flag, if this element may
have starting style and specifies transitions, we resolve the
starting style. Use it as the before-change style.
The implmentation in process_animations() and tests are in the following
patches.
Differential Revision: https://phabricator.services.mozilla.com/D208570
The rules inside @starting-style doesn't apply to primary style, and
they are used only for CSS transitions (when computing starting style).
So adding a flag to make us easier to filter them out.
Differential Revision: https://phabricator.services.mozilla.com/D208569
The values that we take from our parent should be zoomed in. Similarly,
root values should also be zoomed in by the effective zoom (for that, we
unzoom root values to zoom-independent pixels when storing them on the
device).
Container-relative units probably need more care / thought, because they
are in the layout (so zoom-independent) coordinate space already, since
they come from frames. Bug 1894104 is filed for this.
Differential Revision: https://phabricator.services.mozilla.com/D208599
For the selector highlighter, we were retrieving the desugared selector of each
displayed rule, and using the selector text in querySelectorAll to retrieve the
elements matching the rule.
This can be very expensive, especially for deeply nested rule, for a feature that
might not even be used.
This patch is adding a method which takes a root node, and will return the
elements inside the root node that match the rule's selectors.
We're only exposing the method that existed in glue.rs to get the SelectorList
of a given Rule, and call `Servo_SelectorList_QueryAll` with it to get our NodeList.
A test file is added to ensure this works as expected.
Differential Revision: https://phabricator.services.mozilla.com/D208363
We can have combinator sequences like [>, <part>], and they are fine.
Add a test to make sure they're handled correctly.
Differential Revision: https://phabricator.services.mozilla.com/D208668
- Rename ColorParser to ComponentParser.
- Move origin color parsing to parse_color_function.
- Inline the parse_components function.
Differential Revision: https://phabricator.services.mozilla.com/D207836
- Rename ColorParser to ComponentParser.
- Move origin color parsing to parse_color_function.
- Inline the parse_components function.
Differential Revision: https://phabricator.services.mozilla.com/D207836
When an origin color is specified in RCS, using the channel keywords
from the original color should be replaced by the values from the origin
color.
Differential Revision: https://phabricator.services.mozilla.com/D207117
In some cases, it can be more useful to only get the token value than the whole
token text (e.g. for 'Function`, where the value is the function name, while
the text includes the opening parenthesis)
Refactor `test_lexer` to better test the tokens we get, including their value property.
Differential Revision: https://phabricator.services.mozilla.com/D207400
This new InspectorCSSParser makes use of the cssparser crate so DevTools end
up using the same code as the CSS engine.
At the moment, we can't get the token start and end offsets, so we create
a JS wrapper class to compute them in JS. This might be removed if we get
a way to retrieve utf16 position from the cssparser.
The existing lexer xpcshell test is modified so it can run against both js-based
and rust-based lexers.
Differential Revision: https://phabricator.services.mozilla.com/D202909
When an origin color is specified in RCS, using the channel keywords
from the original color should be replaced by the values from the origin
color.
Differential Revision: https://phabricator.services.mozilla.com/D207117
We were getting a line byte index for the
actual char matching the line we want, but
we actually need the index _after_ that
new line char.
A test case is added to cover this fix.
Differential Revision: https://phabricator.services.mozilla.com/D207156
The ColorParser trait only has one implementation so we can make it a
concrete type now. It will be extended in the future.
Differential Revision: https://phabricator.services.mozilla.com/D207009
This abstraction was in place when the color parsing still lived in
the cssparser crate, but now it is not needed any more and by removing
it we make the parsing more flexible.
Note: the ColorParser trait itself is still in tact and will be
addressed in another patch.
Differential Revision: https://phabricator.services.mozilla.com/D207008
No behaviour is changed and the functions are only merged to a single
more generic version. Avoid code duplication and will make future
changes much easier and less error prone.
Differential Revision: https://phabricator.services.mozilla.com/D206993
`InspectorUtils.getRuleBodyTextOffset` was returning bytes position, and we
were using them directly in Javascript `substring`, which causes problem
with non-ascii chars.
Instead of returning offsets to compute the rule string, we directly return
the string from InspectorUtils which is easier to work with.
Differential Revision: https://phabricator.services.mozilla.com/D204523
The next patch modifies `getRuleText` so it only returns the text, and no
longer the offset at which the rule starts.
The only consumer of the returned offset was in `StyleRuleActor#setRuleText`,
so we migrate this directly to a InspectorUtils method to avoid mixing JS string
indexes with Rust bytes position.
Differential Revision: https://phabricator.services.mozilla.com/D204522
We introduce this rule and parse it in this patch. Also, fix some wpt
expectations for ERROR.
We will introduce CSSStartingStyleRule in the following patch, and test
it there.
Differential Revision: https://phabricator.services.mozilla.com/D206428
We introduce this rule and parse it in this patch. Also, fix some wpt
expectations for ERROR.
We will introduce CSSStartingStyleRule in the following patch, and test
it there.
Differential Revision: https://phabricator.services.mozilla.com/D206428
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
* Linux doesn't support them already.
* macOS doesn't draw anything either.
* Windows doesn't have dark-color-scheme support so the relevant
windows that have them need to set appearance none already.
Remove them and simplify the relevant code.
Differential Revision: https://phabricator.services.mozilla.com/D205872
This is simpler given we only have a couple of windows with these looks,
and removes the dual mode of the ToolbarWindow class.
We just draw the title into the window frame and rely on CSS reserving
enough space (exposed as a new -moz-mac-titlebar-height environment
variable).
We remove the toolbox and toolbar appearance values on mac, now that
they do nothing (toolbar did, but it didn't support dark mode and is
effectively unused).
Differential Revision: https://phabricator.services.mozilla.com/D205469
Basically, we implement `Animate` for `PathOrShapeFunction` manually
when either *from* or *to* value is `path()` function, and the other one
is `shape()` function.
Differential Revision: https://phabricator.services.mozilla.com/D205491
This matches what WebKit and Blink ship. Bug 1887627 is the more complex
fix, though I'm a bit concerned about the performance implications
there, and I don't think that necessarily blocks shipping zoom...
This should be uncontroversial and unblocks getting zoom out of the
door.
Differential Revision: https://phabricator.services.mozilla.com/D205562
We treat it as other basic shapes (excluding path(), which has some
special handling and it doesn't rely on the current layout position).
Therefore, we don't have any implementation for caching and we would like to
leave this part to Bug 1837042.
Also, add some more simple tests in css/motion to make sure we render it
properly.
Differential Revision: https://phabricator.services.mozilla.com/D204440
* Linux doesn't support them already.
* macOS doesn't draw anything either.
* Windows doesn't have dark-color-scheme support so the relevant
windows that have them need to set appearance none already.
Remove them and simplify the relevant code.
Differential Revision: https://phabricator.services.mozilla.com/D205872
This is simpler given we only have a couple of windows with these looks,
and removes the dual mode of the ToolbarWindow class.
We just draw the title into the window frame and rely on CSS reserving
enough space (exposed as a new -moz-mac-titlebar-height environment
variable).
We remove the toolbox and toolbar appearance values on mac, now that
they do nothing (toolbar did, but it didn't support dark mode and is
effectively unused).
Differential Revision: https://phabricator.services.mozilla.com/D205469
We have shipped them for more than 3 months and we don't have issue
right now. Chromium also removed the flags, so it should be fine to drop
them to make the code simpler.
Differential Revision: https://phabricator.services.mozilla.com/D205615
It's possible to set `animation-name` to any of the keyword of other
properties, and this may cause ambiguity when serializing `animation`
shorthand (because we may reuse this result as an input of another
`animation` shorthand to get the same result).
So we still have to serialize these properties even if they are initial
values if `animation-name` matches them.
e.g.
Set `animation` to `normal normal`. Its serialization should be
`normal normal`, instead `normal`, because using `normal` as an input of
another `animation` shorthand makes its `animation-name` be `none`.
(Note: we parse `animation-direction` first.)
Differential Revision: https://phabricator.services.mozilla.com/D204995
We still have some ambiguous issue when `animation-name` is the same as
other keywords. We will fix it in the following patch.
Differential Revision: https://phabricator.services.mozilla.com/D204692
It's possible to set `animation-name` to any of the keyword of other
properties, and this may cause ambiguity when serializing `animation`
shorthand (because we may reuse this result as an input of another
`animation` shorthand to get the same result).
So we still have to serialize these properties even if they are initial
values if `animation-name` matches them.
e.g.
Set `animation` to `normal normal`. Its serialization should be
`normal normal`, instead `normal`, because using `normal` as an input of
another `animation` shorthand makes its `animation-name` be `none`.
(Note: we parse `animation-direction` first.)
Differential Revision: https://phabricator.services.mozilla.com/D204995
We still have some ambiguous issue when `animation-name` is the same as
other keywords. We will fix it in the following patch.
Differential Revision: https://phabricator.services.mozilla.com/D204692
This is significantly faster. While at it:
* Remove unused "additional_methods".
* Fix help text to remove an option that no longer exists.
Differential Revision: https://phabricator.services.mozilla.com/D205047
Substring attribute selectors should never match when an empty string is
provided. This fixes [attr^=""], [attr$=""], [attr*=""] and [attr~=""]
in Servo, which broke when D180529 removed never_matches.
Gecko doesn't use this code at all, so no change in behavior.
Differential Revision: https://phabricator.services.mozilla.com/D205187
Instead of Option<ElementSelectorFlags>, it can be ElementSelectorFlags,
representing None as ElementSelectorFlags::empty().
No change in behavior.
Differential Revision: https://phabricator.services.mozilla.com/D205051
Update clip-path-shape-003.html and clip-path-shape-004.html because
1. Per SVG2 spec, we don't accept comma among commands, so I remove them.
2. Basically, these two tests want to test the result of `shape()`
should be identical to the result of `path()`. However, I noticed the
original tests which put a `clip-path:path()` with `position:absolutely`
may have a fuzzy result if the path has some curves there. This may be
caused by anti-alias together with absoultely positioned element
(note: perhaps there are some floating point calculation in layout for
this, so the final rendering coordinates may have some fractions).
Therefore, I drop the absolutely positioned element, and just test
that if the result of `shape()` is identical to the result of `path()`.
Also, add two more tests for different reference-boxes together with
the usage of `shape()` (to make sure we resolve percentage values properly).
Differential Revision: https://phabricator.services.mozilla.com/D202884
Also, we don't have Unkonwn type, so we have to do some minor
refactoring in BuildPath(), and templatize this function so we can use
it for both shape() and path().
This patch doesn't change the behavior.
Note that we instantiate BuildPath() with CSSFloat for now. Once we
instantiate it for StyleAngle and LengthPercentage (i.e. shape()), we
have to tweak this function more. Let's do that in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D202883
Implement the style part for shape(). Besides, update some issues in the
test file, e.g. avoid using viewport height so we get the fixed result
on different devices.
I will refactor `PathCommand` to let it be a specialization of
`GenericShapeCommand` in the following path.
Differential Revision: https://phabricator.services.mozilla.com/D202882
There are still some unhandled edge cases, like making the removal of an
@property rule not interpolate (bug 1885798).
Also, a todo is added to more granularly handle custom properties in
is_discrete_animatable (bug 1885995).
Differential Revision: https://phabricator.services.mozilla.com/D204863
This should be flexible enough. In the future Servo might want to make
more guarantees about what threads the style thread pool contains.
Differential Revision: https://phabricator.services.mozilla.com/D204506
The parsing functions now return typed values like NumberOrPercentage or
NumberOrAngle and only once they are converted to AbsoluteColor (which
will change in the near future to accommodate RCS) are they converted to
f32 values.
Depends on D203465
Differential Revision: https://phabricator.services.mozilla.com/D203410
With nesting it might not hold. It still doesn't change the correctness
of that code tho. We might need to rework this a bit more in the future
to handle specificity properly, see linked spec issue.
But for now crashing is not useful at all.
Differential Revision: https://phabricator.services.mozilla.com/D204304
Add a TODO for bug 1883255, since D203361 fixes bug 1870348.
Add a TODO for bug 1884606, since WPTs for interpolating custom
properties with syntax `<transform-function>` and with value `none` now
fail.
Differential Revision: https://phabricator.services.mozilla.com/D203361
Unparsed custom properties are the
ComputedRegisteredValueInner::Universal variant.
Although the inner value is the ComputedRegisteredValueInner type,
custom property maps hold only the
ComputedRegisteredValueInner::Universal variant to keep behavior
unchanged for now.
D203360 also removes Arc<> from the CustomPropertiesMap value.
Differential Revision: https://phabricator.services.mozilla.com/D203360
Now that registered custom property values contain URL data, URL data is
eliminated as an argument in some places, and the ComputedValue.url_data
field is removed.
Differential Revision: https://phabricator.services.mozilla.com/D203359
The URL data is necessary to uncompute the value for animation. This was
handled previously by adding the URL data to CustomAnimatedValue.
However, now that a registered custom property is passed to
CustomAnimatedValue::from_computed instead of a VariableValue, that
registered custom property should include URL data.
Differential Revision: https://phabricator.services.mozilla.com/D203358
Add a TODO for bug 1883255, since D203361 fixes bug 1870348.
Add a TODO for bug 1884606, since WPTs for interpolating custom
properties with syntax `<transform-function>` and with value `none` now
fail.
Differential Revision: https://phabricator.services.mozilla.com/D203361
Unparsed custom properties are the
ComputedRegisteredValueInner::Universal variant.
Although the inner value is the ComputedRegisteredValueInner type,
custom property maps hold only the
ComputedRegisteredValueInner::Universal variant to keep behavior
unchanged for now.
D203360 also removes Arc<> from the CustomPropertiesMap value.
Differential Revision: https://phabricator.services.mozilla.com/D203360
Now that registered custom property values contain URL data, URL data is
eliminated as an argument in some places, and the ComputedValue.url_data
field is removed.
Differential Revision: https://phabricator.services.mozilla.com/D203359
The URL data is necessary to uncompute the value for animation. This was
handled previously by adding the URL data to CustomAnimatedValue.
However, now that a registered custom property is passed to
CustomAnimatedValue::from_computed instead of a VariableValue, that
registered custom property should include URL data.
Differential Revision: https://phabricator.services.mozilla.com/D203358
During an animation restyle, two links might share the same rules while
not sharing the same link-ness.
This is a temporary state, but let's deal with it correctly.
Differential Revision: https://phabricator.services.mozilla.com/D203891
This was done using bindgen's "emit_diagnostics" feature, which shows
unused allowlist entries.
Enabling it by default would need extra dependencies so for now don't.
Differential Revision: https://phabricator.services.mozilla.com/D203533
Even if `mask-origin` is at its initial value `border-box`, we still have to
serialize it to avoid ambiguity iF the `mask-clip` longhand has some other
`<coord-box>` value (i.e. neither `border-box` nor `no-clip`).
Differential Revision: https://phabricator.services.mozilla.com/D203209
The regressing bug regressed some calc() expressions like the one in the
test-case:
max-width: calc(100% - <some-fixed-length>);
Where floating point precision basically made us lose a little bit of
precision here and there.
Before bug 1841612, this worked because we'd operate in fixed point for
such simple expressions at least. Things could easily go equally south
for more complex things including e.g. rem().
Rounding seems like the better default for calc() since we basically
have no idea of what the output is going to be, and makes the answer
more likely to be precise.
Note that this only affects actual mixed calc() expressions: If things
resolve to a percentage we keep existing behavior.
Differential Revision: https://phabricator.services.mozilla.com/D202746
In order to do it, expose the button padding to CSS via env(), and make
the buttons just use the regular drawing.
This slightly changes the padding to the end of the titlebar to match
one half of the inter-button spacing, rather that however much padding
the headerbar has.
We could improve on this slightly by also exposing the headerbar padding
and applying that to the last button, but that's not terribly easy to do
due to us supporting re-ordering of the titlebar buttons, and reversing
their placement, so it'd involve some rather hacky CSS. Not impossible,
but not trivial, and this looks good enough IMO.
Differential Revision: https://phabricator.services.mozilla.com/D202616
This will allow calling InspectorUtils.ColorTo("red", "lab") and
receive {color: "lab(54.3 80.8 69.9)", components: [54.3, 80.8, 69.9, 1.0], adjusted: false}.
The adjusted value is always "false", because gamut checking and mapping
is not supported at the moment. See:
https://bugzilla.mozilla.org/show_bug.cgi?id=1823363
Depends on D192673
Differential Revision: https://phabricator.services.mozilla.com/D169942
This function allows writing colors as authored values so that it can
be used in the frontend (devtools) and diplayed to users.
Mostly this avoid serializing hsl/hwb to rgb format like it does for
specified/computed values. For lab/lch/etc. it uses percentages and
angles to make it more clear to authored.
Depends on D192672
Differential Revision: https://phabricator.services.mozilla.com/D192673
When transition-behavior is allow-discrete, the animation values are
transitionable even if they are not interpoltable, given that the
animation type of the CSS property is by computed value.
Also, we remove `animate()` check from `needs_transitions_update_per_property`.
This check was added for handling the transition between `auto` and
other values long time ago, but now it may be redundant (because we
still pass the tests without it) and we do the same things in
nsTransitionManager as well, so it should be fine to drop it, especially
after we support discrete transitions.
Differential Revision: https://phabricator.services.mozilla.com/D201865
The implementation is straight-forward. We have to check
if `transition-behavior` is `allow-discrete` when trying to create a new
transition and when checking if we have to cancel a running transition.
Also, the test case is out-of-date, so I tweak it a little bit and add
more general test cases for transtiion-behavior. Besides, I enable the
preference in the WPT folders which use `transition-behavior` (but
those tests may be passed already or failed due to reasons other than
`transition-behavior`).
Differential Revision: https://phabricator.services.mozilla.com/D201864
Was added in bug 1793012. No longer needed since `:has` is part of
reinvalidation selectors now. The new approach can be potentially-
pricey, but is a lot simpler.
Differential Revision: https://phabricator.services.mozilla.com/D200224
Would generate invalid results `:has()` selector if it's in the subject
compound but also uses a pseudo-selector (e.g. `.foo:has(.bar)::after`).
Also rename `Rightmost` to `SubjectOrPseudoElement` to more accurately
describe what it indicates.
Differential Revision: https://phabricator.services.mozilla.com/D200222
This speeds up custom variable substitution by avoiding re-tokenizing,
and variable reference parsing by avoiding doing duplicate work.
This is a very noticeable improvement in the NewsSite subtests of
speedometer 3 (see comparison posted in bug 1879318 and the #perf-sp3
matrix channel). But it also probably helps most websites using lots of
variables, and the browser UI itself.
Finally, it also avoids some duplication. Now regular substitution and
fallback substitution is handled uniformly, which causes a progression
in some properties-and-values tests.
Differential Revision: https://phabricator.services.mozilla.com/D201116
This is a preliminary patch to keep all references (even duplicates), in
order to speed up substitution by avoiding re-tokenizing.
The assumption is that referencing the same variable multiple times
on the declaration is not common, and thus it's not a big deal to
optimize for that.
Differential Revision: https://phabricator.services.mozilla.com/D201082
Inherited properties with universal syntax and unregistered properties should
behave basically the same.
This removes some redundant checks and guarantees that we have the same
code-paths in those two cases.
Differential Revision: https://phabricator.services.mozilla.com/D200995
Reduce the amount of times we need to manually call the custom property
registration code by handling values with and without references in the same
function.
Differential Revision: https://phabricator.services.mozilla.com/D200993
Older versions of the yaru theme had dark titlebars even in light mode
(like yaru-remix).
Instead of getting into the version-detection business, just don't
override with the Adwaita colors.
Differential Revision: https://phabricator.services.mozilla.com/D200362
Note that although this builds, it would (by itself) result in some test breakage;
this is resolved in the following patches that build on this.
Differential Revision: https://phabricator.services.mozilla.com/D198790
Note that although this builds, it would (by itself) result in some test breakage;
this is resolved in the following patches that build on this.
Differential Revision: https://phabricator.services.mozilla.com/D198790
* Move the manual code outside the auto-generated animated_properties
file.
* Treat unregistered custom properties and universal-syntax properties
the same.
* A void a bunch of copy-pasta and extra unnecessary clone() calls.
* Fix animations with mismatched multipliers, custom property names,
etc. This isn't really testable, since afaict you can't create such
an animation (maybe if you override the registration dynamically?),
but seems better for consistency.
Differential Revision: https://phabricator.services.mozilla.com/D199365
Note that although this builds, it would (by itself) result in some test breakage;
this is resolved in the following patches that build on this.
Differential Revision: https://phabricator.services.mozilla.com/D198790
Dependencies between custom properties and font-* properties are
resolved in bug 1855110, so these TODOs for bug 1856522 can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D199208
Resolution of such custom properties (And other properties depending on them)
must take place after font-related properties (Which are prioritary) are
resolved. Resolution of custom properties is therefore split into two phases,
before and after prioritary properties are resolved.
Differential Revision: https://phabricator.services.mozilla.com/D196195
Registered custom properties may utilize font-relative units such as `em`,
`ex`, etc. Font-related properties (More with `calc()` unit algebra), in
turn, may refer to such registered custom properties, leading to a cycle
(Note, unregistered properties are effectively copy-pastes, so it does not
suffer from this issue).
This patch:
1. Defers computation of registstered custom properties using font-relative
units
2. Keeps track of custom properties utilizing font-relative units
3. Keeps track of non-custom, font-related properties making variable
references
4. Expands the cycle detection to non-custom properties
Because of 1, this patch causes registered custom property using
font-relative units to resolve as if they're unregistered - this will be
addressed in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D196194
This implements a similar optimization as WebKit's, see the bug comment.
This should be specially useful for sites with lots of custom
properties.
This is a high-confidence win on this speedometer subtest:
* 1.9x faster in style updates.
* 4.2x faster in layout object destruction (we no longer free the huge
custom properties map).
* Also speeds up paint and layout a bit, probably from less memory
churn.
Differential Revision: https://phabricator.services.mozilla.com/D198308
After the regressing bug, first-line reparenting starts off with the
to-be-reparented style, so the display value is already the expected
(grid) rather than block.
Differential Revision: https://phabricator.services.mozilla.com/D197251
-moz-window-shadow is a chrome-only property (not exposed to the web),
and chrome stylesheets only use the none value to disable the default
behavior.
Split the style property (default/none) from the actual widget behavior.
This is useful because I want to add a distinction between
natively-styled menupopups and other panels in the following commit.
While at it rename default to "auto" which is a more common name in CSS
for something like this.
We have no use case for removing the shadow of a top-level window, so
remove it to simplify the code.
Differential Revision: https://phabricator.services.mozilla.com/D197454
-moz-user-focus: none didn't do anything useful for non-XUL until
bug 1868552. It seems nonetheless some sites specify it, which can cause
compat issues.
Let's hide this property from content, to avoid breaking those sites.
Differential Revision: https://phabricator.services.mozilla.com/D197253
1.76 added a warning when comparing pointers with metadata (e.g. a size
or trait vtable), and suggests to use explicit comparisons, either
std::ptr::addr_eq to only compare the address or std::ptr::eq to compare
address + metadata.
The current semantics of Arc::ptr_eq are to compare address + metadata,
but the intended semantics are to compare the address. So we do that.
Differential Revision: https://phabricator.services.mozilla.com/D197275
-moz-user-focus: none didn't do anything useful for non-XUL until
bug 1868552. It seems nonetheless some sites specify it, which can cause
compat issues.
Let's hide this property from content, to avoid breaking those sites.
Differential Revision: https://phabricator.services.mozilla.com/D197253
This got reviewed as part of D196842 (see diff 801914), but I rebased
before landing in a tree that didn't have that change.
MANUAL PUSH: Orange fix CLOSED TREE
Make NonCustomPropertyId an u16 (because it can, and it's more compact),
and use arrays for ShorthandId::longhands and LonghandId::shorthands.
Differential Revision: https://phabricator.services.mozilla.com/D196759
By using a opaque-appearance widget (which is effectively what
appearance: -moz-dialog used to provide).
There's the question of whether we want the current vibrant titlebars,
but this restores the behavior precisely for now.
Differential Revision: https://phabricator.services.mozilla.com/D196712
This patch also updates the bug ID for a FIXME leftover from bug 1840478
to bug 1869476, since the same FIXME is added in D190758.
Co-authored-by: Frederic Wang <fred.wang@free.fr>
Depends on D191322
Differential Revision: https://phabricator.services.mozilla.com/D190758
This will make possible to animate custom properties. For now, the
animation code keeps only dealing with PropertyDeclarationId::Longhand,
so behavior is unchanged.
Co-authored-by: Frederic Wang <fred.wang@free.fr>
Depends on D195972
Differential Revision: https://phabricator.services.mozilla.com/D190816
PropertyId predates NonCustomPropertyId. Now that we have it, we can
clean up a bit the code.
The idea is to make PropertyId and AnimatedPropertyId basically the
same, so that conversions can be improved in bug 1846516.
While at it make NonCustomPropertyId a u32.
Differential Revision: https://phabricator.services.mozilla.com/D196415
Because PropertyDeclarationId and its implementation do not make use of
templating, we might as well move it out of mako.
This will be useful later when creating OwnedPropertyDeclarationId,
which can be added to the same module.
Differential Revision: https://phabricator.services.mozilla.com/D195972
Gregory Pappas
Narcis Beleuzu
Emilio Cobos Álvarez
Noemi Erli
David Shin
Zach Hoffman
Tiaan Louw
Erich Gubler
Boris Chiou
Nicolas Chevobbe
Tamas Szentpeteri
Emily McDonough
Sandor Molnar
Aron Cseh
Ashley Hale
Cristian Tuns
Jan-Niklas Jaeschke
Stanca Serban
Mike Hommey
keithamus
Norisz Fay
Niels
Oriol Brufau
Vincent Hilla
Natalia Csoregi
serge-sans-paille
Jonathan Kew
Liu
Peter Van der Beken
Frédéric Wang
sunil mayya
Forrest Walker
Iulian Moraru
Robert Longson
Connor Pearson
Ziran Sun
Makoto Kato
Eliot Jacobs
Cosmin Sabou