252241 - -moz-border-radius on boxes over ~32,000px high place background outside the box

Status: RESOLVED FIXED

(Core :: Web Painting, defect)

Description

[Perry Lorier]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.1) Gecko/20040715 Debian/1.7.1-1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.1) Gecko/20040715 Debian/1.7.1-1

If you have a style with a -moz-border-radius that's over ~32,000px high, with a
background colour, then the background is painted on the webpage *above* the box.

Suspected problem: Somethings stored in a signed 16bit value and it wraps
negative.  It's not exactly 32768px that the issue occurs, however around that
point weird things happen with borders, I suspect that it's 32768 with some fuzz
for the border radius.

Solution of course would be to use a 32bit int

Reproducible: Always
Steps to Reproduce:
1. visit testcase at:
http://coders.meta.net.nz/~perry/docs/docmaker/test.html


Actual Results:  
2. Observe that the area above the div is painted instead of the interior.

Expected Results:  
painted the interior of the div.

Comment 1

[Perry Lorier]

Attachment: Testcase demonstration the bug.

Attached minimal testcase.

Comment 2

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

testcases WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3)
Gecko/20040719.

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

There's a lot of bugs like this --- problems with 16bit widgets and graphics
coordinates... Try a GTK2 build

Comment 4

[Andrew Schultz]

*** Bug 277714 has been marked as a duplicate of this bug. ***

Comment 5

[Andrew Schultz]

FYI: the bug also exists with GTK2

Comment 6

[Braden]

I am no longer seeing this in Mozilla 1.7.6. Or rather, I am no longer seeing
bug 277714.

Comment 7

[Andrew Schultz]

I'm still seeing both this and bug 277714 (at least with my testcase, the URL is
gone) with linux trunk 2005032605.  It's unlikely anything like this got fixed
on the 1.7 branch.

Hmm, but firefox trunk with gtk2 now works.  So perhaps a gtk1 bug.

Comment 8

[Braden]

I'm using GTK2.

Comment 9

[Braden]

And nevermind. I was mistaken; it's still broken for me as well.

Comment 10

[Boris Zbarsky [:bzbarsky]]

So the issue here is that nsRenderingContextGTK::FillPolygon (called by nsCSSRendering::DrawRoundedBackground) gets coordinates that overflow the 16-bit coordinate system of GTK widgets and ends up painting in various random places as a result.

roc, vlad, will this be solved automagically with cairo?  If so, could you please mark this dependant on the relevant bug?  If not, is there something like ConditionRect that we could do here to make this happy?

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I tried to write a ConditionRect for FillPolygon once, but I couldn't think of an efficient and correct way to do it -- see bug 115526.  (There are a whole bunch of edge cases that are hard to get right.)

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(That said, somebody with a better graphics background could probably do it more easily, since they wouldn't be trying to figure out the algorithms from scratch.)

Comment 13

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

It should be automagically solved, yeah; I don't think we have a relevant bug yet, but it would be something along the lines of "change CSSRendering to use direct Thebes APIs", I think.

Comment 14

[Boris Zbarsky [:bzbarsky]]

The reason I was wondering is that Thebes GFX still has a ConditionRect method, implying that it suffers from these same issues...

Comment 15

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

(In reply to comment #14)
> The reason I was wondering is that Thebes GFX still has a ConditionRect method,
> implying that it suffers from these same issues...

It does, due to a current (acknowledged) bug in cairo (it doesn't clip trapezoids to the surface bounding box before compositing them).  Once that bug's fixed, our ConditionRect won't be needed any more.  I figure that bug will be fixed quite soon :)

Comment 16

[Zack Weinberg (:zwol)]

This WORKSFORME with Firefox 3.5 (distro build) and trunk on Linux, and based on the audit trail, I am guessing it was fixed in Thebes some time ago.  Closing.