Some of the stuff, in particular inside GeckoBindings stuff should be
refactored to be less ugly and duplicate a bit less code, but the rest of the
code should be landable as is.
Some invalidation changes are already needed because we weren't matching with
the right shadow host during invalidation (which made existing ::part() tests
fail).
Pending invalidation work:
* Making exportparts work right on the snapshots.
* Invalidating parts from descendant hosts.
They're not very hard but I need to think how to best implement it:
* Maybe get rid of ShadowRoot::mParts and just walk DOM descendants in the
Shadow DOM.
* Maybe implement a ElementHasExportPartsAttr much like HasPartAttr and use
that to keep the list of elements.
* Maybe invalidate :host and ::part() together in here[1]
* Maybe something else.
Opinions?
[1]: https://searchfox.org/mozilla-central/rev/131338e5017bc0283d86fb73844407b9a2155c98/servo/components/style/invalidation/element/invalidator.rs#561
Differential Revision: https://phabricator.services.mozilla.com/D53730
At first I thought this was going to enable simplifications in the selector
parser (to simplify the attribute selector setup), but I couldn't end up
shrinking the layout enough.
However this should help with bug 1559076, which returns Option<Atom>, and it
was easy to write.
Differential Revision: https://phabricator.services.mozilla.com/D53766
When we physicalize the declarations for @keyframes, we end up having a physical
declaration with an unparsed value with `from_shorthand` being the logical
shorthand.
Account for this case properly when substituting custom properties, to avoid
panicking.
Differential Revision: https://phabricator.services.mozilla.com/D53663
The micro-benchmark `style-attr-1.html` regressed slightly with my patch, after
the CascadeLevel size increase.
This benchmark is meant to test for the "changing the style attribute doesn't
cause selector-matching" optimization (which, mind you, keeps working).
But in the process it creates 10k rules which form a perfect path in the rule
tree and that we put into a SmallVec during the cascade, and the benchmark
spends most of the time pushing to that SmallVec and iterating the declarations
(as there's only one property to apply).
So we could argue that the regression is minor and is not what the benchark is
supposed to be testing, but given I did the digging... :)
My patch made CascadeLevel bigger, which means that we create a somewhat bigger
vector in this case. Thankfully it also removed the dependency in the
CascadeLevel, so we can stop using that and use just Origin which is one byte to
revert the perf regression.
Differential Revision: https://phabricator.services.mozilla.com/D53181
For the individual transform properties if they spec a value that can be
expressed as 2d we treat as 2d and serialize accordingly.
We drop Translate::Translate and Scale::Scale, and then rename
Translate::Translate3D as Translate::Translate, Scale::Scale3D as
Scale::Scale. So now we use Translate::Translate to represent 2d and 3d
translation, and Scale::Scale to represent 2d and 3d scale. There is no
difference between 2d and 3d translate/scale in Gecko because we always
convert them into 3d format to layers (on the compositor thread), so this
change makes things simpler.
Differential Revision: https://phabricator.services.mozilla.com/D52931
Move all the entires of SpecialColorKeyword into SystemColor
and rearrange their computation to match.
Add the new SystemColor entries into the property list of nsXPLookAndFeel.
Differential Revision: https://phabricator.services.mozilla.com/D50903
Now
* nsPresContext::mVisibleArea is excluding the toolbar max height so that
ICB is now static regardless of the dynamic toolbar transition
* nsPresContext::mSizeForViewportUnits is introduced to resolve viewport units
which is including the toolbar max height
That means that with the dynamic toolbar max height;
mVisibleArea < mSizeForViewportUnits
See https://github.com/bokand/URLBarSizing for more detail backgrounds of this
change.
Depends on D50417
Differential Revision: https://phabricator.services.mozilla.com/D50418
The existing code wasn't sound, as CSSOM objects also needed to go away before
the shared memory goes away (as they keep references to them).
This is sound assuming no presence of reference cycles introduced by CSSOM.
We may want to live with this and rely on chrome code not writing cycles like
this with UA stylesheet DOM objects.
We could explicitly drop all potentially-static objects... That seems pretty
error prone though.
Or we could also just leak the shared memory buffer, is there any reason why we
may not want to do that?
Differential Revision: https://phabricator.services.mozilla.com/D51870
This matches the WebKit implementation, and is clearly a violation of the rules
we generally use for ranges in CSS.
But it seems to be depended-on legacy behavior, see the linked WebKit bug, this
bug, and bug 1593317.
Differential Revision: https://phabricator.services.mozilla.com/D51539
And do a full restyle only when the state goes from visited to unvisited or vice
versa. That is, use regular invalidation for addition or removals of href
attributes, for example.
Differential Revision: https://phabricator.services.mozilla.com/D50821
We need to pass these two types into the compositor, so we need a better
way to serialize these rust types. We use serde and bincode to
serialize/deserialize them, and use ByteBuf to pass the &[u8] data
through IPC. We define StyleVecU8 for FFI usage only.
Differential Revision: https://phabricator.services.mozilla.com/D50688
This also includes the implementation of SetAnimatable, FromAnimatable,
and merge the final matrix with motion path.
Besides, we always use PathBuilderSkia for calculating the gfx::Path for
web-renderer.
Differential Revision: https://phabricator.services.mozilla.com/D50011
This is a gross hack, of course, but has the advantage of not breaking sites
that use both zoom and -moz-transform / -moz-transform-origin.
There should be no behavior change when the pref is off, of course, and the
webcompat team wanted to experiment with this.
Differential Revision: https://phabricator.services.mozilla.com/D49792
