Closed Bug 399258 Opened 17 years ago Closed 17 years ago

the outline of the border for -moz-border-radius is not shown in particular circumstances

Categories

(Core :: Layout, defect, P4)

defect

Tracking

()

RESOLVED FIXED

People

(Reporter: martinandalex, Assigned: roc)

References

Details

(Keywords: regression, testcase)

Attachments

(2 files)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007100505 Minefield/3.0a9pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007100505 Minefield/3.0a9pre The algorithm/condition to determine whether to draw the curved border is incorrect and is appears to still based on conditions which determine whether to draw a standard rectangular border, which means that at times the border outline is not drawn when in fact it should be. Reproducible: Always Steps to Reproduce: 1. The following code fragment will correctly display a blue rectangle with a thick black border. <div id="test" style="position:absolute; background-color:#0000ff; border: 10px solid #000000; left:-25px; top :-25px; width : 3000px; height:3000px; -moz-border-radius : 160px; "> </div> Actual Results: 1. Notice that the top-left hand curved corner still appears as expected but the black outline has not been drawn. 2. Note that if you change the width and height to say 300px, then everything works as it should. Expected Results: Whenever we see a curved blue region then we should also see a black outline. reiterating: The algorithm/condition to determine whether to draw the curved border is incorrect and is appears to still based on conditions which determine whether to draw a standard rectangular border.
sorry, i am new to bug submission and don't know if/how i can edit my own bug report (hence the duplicate bug 399256). In the reproducibility section step 1 should read: 1. The following code fragment *SHOULD* display a blue rectangle with a rounded top-left hand corner with a thick black outline. But it does *NOT*.
You (or I) can't edit your comments, but you can always rectify earlier comments in a new additional comment :). This regressed on 30 Apr 2007 probably by the fix of Bug 368247.
Blocks: 368247
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Version: unspecified → Trunk
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression, testcase
I see this on Linux as well.
OS: Windows XP → All
Hardware: PC → All
Flags: blocking1.9?
Flags: blocking1.9? → blocking1.9+
Priority: -- → P4
This should be pretty easy to fix so I'll try to get it fixed for 1.9. We wouldn't block on it though.
Assignee: nobody → roc
Flags: wanted1.9+
Flags: blocking1.9-
Flags: tracking1.9+
Attached patch fix (deleted) — Splinter Review
Let's just remove this incorrect optimization. nsDisplayBorder::OptimizeVisibility does the right thing already so there's no point in optimizing this in PaintBorder as well. http://mxr.mozilla.org/seamonkey/source/layout/base/nsDisplayList.cpp#612
Attachment #315459 - Flags: superreview?(vladimir)
Attachment #315459 - Flags: review?(vladimir)
Attachment #315459 - Flags: superreview?(vladimir)
Attachment #315459 - Flags: superreview+
Attachment #315459 - Flags: review?(vladimir)
Attachment #315459 - Flags: review+
Comment on attachment 315459 [details] [diff] [review] fix fixes a drawing regression, very safe.
Attachment #315459 - Flags: approval1.9?
Comment on attachment 315459 [details] [diff] [review] fix a1.9+=damons
Attachment #315459 - Flags: approval1.9? → approval1.9+
checked in with reftest.
Status: NEW → RESOLVED
Closed: 17 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: