Closed
Bug 383030
Opened 18 years ago
Closed 18 years ago
Negative values for -moz-border-radius/-moz-outline-radius should be ignored
Categories
(Core :: CSS Parsing and Computation, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: martijn.martijn, Assigned: martijn.martijn)
References
(Blocks 1 open bug, )
Details
(Keywords: testcase)
Attachments
(2 files, 1 obsolete file)
(deleted),
text/html
|
Details | |
(deleted),
patch
|
dbaron
:
review+
dbaron
:
superreview+
|
Details | Diff | Splinter Review |
See testcase, the computed style of the various -moz-border-radius and -moz-outline-radius properties return a negative value. According to the border-radius working draft, negative values are not allowed. With new border rewrite, borders/outlines with negative radius values, now look a bit strange.
Comment 2•18 years ago
|
||
Comment on attachment 267047 [details] [diff] [review] patch r+sr=dbaron Could you add an invalid_values item to the test items in layout/style/test/property_database.js as well?
Attachment #267047 -
Flags: superreview+
Attachment #267047 -
Flags: review?(dbaron)
Attachment #267047 -
Flags: review+
Assignee | ||
Comment 3•18 years ago
|
||
Thanks, I was already wondering about how to add a testcase for this.
Attachment #267047 -
Attachment is obsolete: true
Attachment #267058 -
Flags: review?(dbaron)
Comment 4•18 years ago
|
||
Comment on attachment 267058 [details] [diff] [review] patch r+sr=dbaron
Attachment #267058 -
Flags: superreview+
Attachment #267058 -
Flags: review?(dbaron)
Attachment #267058 -
Flags: review+
Assignee | ||
Updated•18 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Updated•18 years ago
|
Assignee: nobody → martijn.martijn
Status: ASSIGNED → NEW
Assignee | ||
Comment 5•18 years ago
|
||
database.js Checking in nsCSSParser.cpp; /cvsroot/mozilla/layout/style/nsCSSParser.cpp,v <-- nsCSSParser.cpp new revision: 3.358; previous revision: 3.357 done Checking in test/property_database.js; /cvsroot/mozilla/layout/style/test/property_database.js,v <-- property_databas e.js new revision: 1.15; previous revision: 1.14 done Checked into trunk.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Updated•18 years ago
|
Flags: in-testsuite+
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5) Gecko/20070606 GranParadiso/3.0a5 ID:2007060601 no check-in to GP a5?
screen-shot: after check-in no.1 [Trunk/2007060504] http://img267.imageshack.us/img267/6307/a1fe9.jpg no.2 [Gran Paradiso/2007060601] http://img509.imageshack.us/img509/3927/a2vx9.jpg before check-in no.3 [Trunk/2007060304] http://img267.imageshack.us/img267/9494/a3fd6.jpg no.2 and no.3 is same result. i.e.)GP-Build ID is newest(build after check-in), but result is same as one(build before check-in). so I asked it.
Comment 10•18 years ago
|
||
OK, If I am not wrong, GP a4(2007042705)/GP a3(2007032219)... have all check-ins before its Build ID. so why a5 says "2007060601", though there are not some check-ins like this bug (this check-in was 20070603**) ? tell me which check-ins are not in a5(from when), if you know ?
Assignee | ||
Comment 11•18 years ago
|
||
Sorry, I don't know. Apparently, the GP a5 tree is somewhat older, although I know there were a few respins.
Comment 12•18 years ago
|
||
A5 RC1 was pulled and built, and then it was later decided to respin for the patch in bug 382482. The tag for the original A5 was used, and the patch for 382482 was applied to it. The build ID is the build time, not source-pull time, so these kinds of things happen.
Comment 13•18 years ago
|
||
(In reply to comment #11) (In reply to comment #12) Thank you for a detailed explanation.
Updated•14 years ago
|
Blocks: border-radius
You need to log in
before you can comment on or make changes to this bug.
Description
•