Closed Bug 1517511 Opened 2 years ago Closed 2 years ago

Simplify storage of computed::LengthOrPercentage and friends.


(Core :: CSS Parsing and Computation, enhancement, P3)




Tracking Status
firefox66 --- fixed


(Reporter: emilio, Assigned: emilio)


(Blocks 1 open bug)



(1 file)

So I was looking at bug 1516454, which caused some test failures, and realized that the failure is that we don't properly preserve the clamping mode when going from Gecko's representation of calc to Servo's.

Then I realized that I could spot-fix that one, but that it was kind of a footgun. So I instead decided to share the representation of LengthOrPercentage between Rust and C++ [1].

That's almost green, though it was a bit more annoying to write than what I expected, mostly because of how we represent it[2], which means that we need to handle lengths and percentages twice.

So it looks to me that there should be no difference in any property between calc(50%) and 50%, for example, so we should be able to represent it as CalcLengthOrPercentage, effectively.

I gave that a try[3], and my naive patch doesn't try to store length or percentages as other than calc() values. It does uncover quite a few issues with our calc() handling in layout and graphics, even assertions.

I'll try to go through some and fix them and then see what remains / if I can land it...

All these issues are reproducible without my patch, by replacing <fixed-length> by calc(<fixed-length>) or <fixed-percentage> by calc(<fixed-percentage>).

This is all so broken :(
Flags: needinfo?(emilio)
Depends on: 1517521
Flags: needinfo?(emilio)
Priority: -- → P3
Depends on: 957915
Flags: needinfo?(emilio)
This is a first step to share LengthOrPercentage representation between Rust and

We need to preserve whether the value came from a calc() expression, for now at
least, since we do different things depending on whether we're calc or not right
now. See and dependent bugs for

That means that the gecko conversion code needs to handle calc() in a bit of an
awkward way until I change it to not be needed (patches for that incoming in the
next few weeks I hope).

I need to add a hack to exclude other things from the PartialEq implementation
because the new conversion code is less lossy than the old one, and we relied on
the lousiness in AnimationValue comparison (in order to start transitions and
such, in [1] for example).

I expect to remove that manual PartialEq implementation as soon as I'm done with
the conversion.

The less lossy conversion does fix a few serialization bugs for animation values
though, like not loosing 0% values in calc() when interpolating lengths and
percentages, see the two modified tests:

 * property-types.js
 * test_animation_properties.html
Pushed by
Simplify computed::LengthOrPercentage and friends. r=heycam
Created web-platform-tests PR for changes under testing/web-platform/tests
Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.
Pushed by
bug 1518098 - followup: Rustfmt so Servo's lints are happy.
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla66
Depends on: 1518954
You need to log in before you can comment on or make changes to this bug.