Fixes an issue where DOMString::is_valid_floating_point_number_string
was returning true for strings that began with whitespace characters-
TAB, LF, FF, or CR. Also added a unit test to cover this since the
corresponding web-platform-tests are incomplete.
Replaced catch-all with explicit case for inputs that do not have
a value sanitization algorithm. This should prevent us from
forgetting to implement a sanitization for an input, since they
must all be accounted for in the match expression.
I see atom dropping code generated in release builds for stuff like dropping the
"class" atom here:
https://searchfox.org/mozilla-central/rev/4df8821c1b824db5f40f381f48432f219d99ae36/servo/components/style/gecko/wrapper.rs#592
That is silly, and I hope making Atom be able to be used in const context will
help the compiler see that yeah, we're not doing anything interesting and the
atom shouldn't get dropped.
It also allows us to get rid of a few lazy_static!s, so we should do it anyway.
In order to accomplish this, compute the offset into gGkAtoms manually instead
of going through the static_atoms() array and then back to the byte offset.
Differential Revision: https://phabricator.services.mozilla.com/D55039
When zoom is disabled, we still count it, but with the current code the testing
function will throw instead of returning the right value, which means we'd fail
layout/style/test/test_use_counters.html.
Differential Revision: https://phabricator.services.mozilla.com/D55005
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
Add CRLF to encoded multipart form data
<!-- Please describe your changes on the following line: -->
Some (3) WPT tests were failing because they expected the body for a multipart form data response to end with a CRLF. So I updated encode_multipart_form_data to add the missing terminator.
Looking at the corresponding spec (https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#multipart%2Fform-data-encoding-algorithm) and RFC (https://tools.ietf.org/html/rfc7578), I couldn't find anything mentioned about this detail.
---
<!-- 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
<!-- Either: -->
- [x] There are tests for these changes
<!-- 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. -->