Closed Bug 1516454 Opened 4 years ago Closed 4 years ago

Computed value of border-radius with calc(percentage) is incorrect


(Core :: CSS Parsing and Computation, defect, P2)




Tracking Status
firefox66 --- wontfix
firefox67 --- fixed


(Reporter: bugzilla, Assigned: emilio)


(Blocks 1 open bug)


(Keywords: testcase)


(3 files, 1 obsolete file)

Reduced test
- - - - - -

Actual result: 8 sub-test failures
eg: the reported computed value of 'border-top-left-radius: calc(50%)' is '0px + 50%'

Expected result: 8 sub-test successes
eg: the reported computed value of 'border-top-left-radius: calc(50%)' should be '50%'

- The original test is:
- I get actual results with Firefox 60.4.0 ESR and with Firefox 66.0a1 buildID=20181226093642
- Chromium 71.0.3578.80 and Epiphany 3.22.7 (WebKit 2.18.6) pass this test
- I searched for a duplicate and did not find any.
Blocks: calc-issues
Keywords: testcase
Always a good excuse to do some cleanup.

Do you plan to submit that test to WPT?
Assignee: nobody → emilio
Flags: needinfo?(bugzilla)
I'll add a test if Gerald is not planning to submit it to WPT soon-ish.

Yes, my initial plan was to submit the original  
(...) third_party/WebKit/LayoutTests/css3/calc/getComputedStyle-border-radius.html
test to WPT. 

I may also submit that Bugzilla-getComputedStyle-border-radius.html test to WPT; I did not consider doing so. I was mainly thinking, focusing about filing a bug report when I created such test. But now that you have brought up this question, it makes sense to submit it too.
Flags: needinfo?(bugzilla)
Priority: -- → P2
Depends on: 1517511


I hope to submit that Bugzilla-getComputedStyle-border-radius.html test under a different and more suitable filename to WPT this week.

As for
it is not clear right now if and if so, when and how it will be submitted to WPT. But the initial desire is to submit it too.

Yup, thanks Gérard! I got somewhat driven away from this trying to clean up all the things, because the patch as-is was getting a few failures. Getting almost there :)

The filename is


and I have created a pull request to submit it to the web platform tests repository:

Integration tests have passed, so now, it is only a matter of getting a reviewer to merge the pull request.

Attachment #9033365 - Attachment is obsolete: true

The euclid size is not really used for anything. Also rename it to Size2D to
avoid cbindgen conflicts with values::length::Size.

Depends on D20958

The test in hasn't been
synced over yet, but it passes with this patch of course.

Depends on D20959

Pushed by
Simplify border-radius serialization. r=firefox-style-system-reviewers,boris
Make the generic size not use euclid under the hood. r=firefox-style-system-reviewers,boris
Pushed by
Use rust lengths for border corners. r=boris
Pushed by
Add some braces on a CLOSED TREE. r=me
Pushed by
Remove an extra brace on a CLOSED TREE, whoops. r=me

Oh, it was a bit tricky to find the actual error from the log:

/builds/worker/workspace/build/src/obj-firefox/dist/include/mozilla/ServoStyleConsts.h:1456:12: runtime error: load of value 228, which is not a valid value for type 'bool'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /builds/worker/workspace/build/src/obj-firefox/dist/include/mozilla/ServoStyleConsts.h:1456:12 in

Well that's interesting. I guess I can do an ASAN build.

Pushed by
Use rust lengths for border corners. r=boris

Oh blerg, of course, StyleBasicShape::mRadius gets compared unconditionally, but only initialized in the Inset case. I didn't realize that nsStyleCorners was PodZero'd

Flags: needinfo?(emilio)
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla67
You need to log in before you can comment on or make changes to this bug.