Closed
Bug 1234409
Opened 9 years ago
Closed 8 years ago
"Assertion failure: mUnit == eCSSUnit_Percent (not a percent value)" with webkit gradient syntax
Categories
(Core :: CSS Parsing and Computation, defect)
Core
CSS Parsing and Computation
Tracking
()
RESOLVED
FIXED
mozilla46
Tracking | Status | |
---|---|---|
firefox46 | --- | fixed |
People
(Reporter: jruderman, Assigned: dholbert)
References
Details
(Keywords: assertion, testcase)
Attachments
(3 files)
With: user_pref("layout.css.prefixes.webkit", true); Assertion failure: mUnit == eCSSUnit_Percent (not a percent value), at nsCSSValue.h:532
Reporter | ||
Comment 1•9 years ago
|
||
Assignee | ||
Comment 2•9 years ago
|
||
So this is a case where: (1) the author provided no color stops, so we pad the color-stop list with 2 transparent stops. (2) the radiuses are in the opposite order that we expect them to be -- the first one is larger -- so we reverse the positions of their color-stops. And the problem is that our auto-generated "padding" color stops from (1) have no position specified, so when we try to inspect their positions in (2), we trip this assertion. The fix is easy -- we should just have dummy 0.0/1.0 (start/end) positions for these transparent padding color stops. All color stops that come from authors will have positions, so our internal auto-generated ones should too.
Assignee | ||
Updated•9 years ago
|
Assignee: nobody → dholbert
Assignee | ||
Comment 3•9 years ago
|
||
Attachment #8701165 -
Flags: review?(cam)
Assignee | ||
Comment 4•9 years ago
|
||
I verified that the added property_database.js line is an effective test for this bug. (With that line, test_value_computation.html trips this bug's fatal assertion, until I apply the fix.)
Assignee | ||
Comment 5•9 years ago
|
||
If you like, for a refresher on why we're messing with these color-stops (beyond comment 2), see these multi-line comments within CSSParserImpl::FinalizeRadialWebkitGradient: http://mxr.mozilla.org/mozilla-central/source/layout/style/nsCSSParser.cpp?rev=1f2dd0904614&mark=10392-10399,10413-10416#10392 The assertion-failure is happening during the call to "colorStop.mLocation.GetPercentValue()" just below the comments there, for a dummy color-stop that we generated in the area of code touched by the patch.
Updated•9 years ago
|
Attachment #8701165 -
Flags: review?(cam) → review+
Comment 7•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/6cdded7c7414
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla46
You need to log in
before you can comment on or make changes to this bug.
Description
•