Closed Bug 538909 Opened 13 years ago Closed 13 years ago

gradient(s) not painted correctly in border-edge

Categories

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

x86
All
defect

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- beta1+
status1.9.2 --- .5-fixed

People

(Reporter: phiw2, Assigned: roc)

References

Details

Attachments

(3 files, 1 obsolete file)

Attached file test case
testcase:
box A, basic: a box with a gradient background and a semi-transparent border - rgba() border-color

AR: the left and top border show the background-color instead of the gradient-colors
ER: the gradient is painted/repeated under all the borders.

More comical - box B in the testcase, using this with '-moz-background-origin: content;' and 'background-repeat: repeat-x;'.

(doing the same with an image shows the correct result)

This is the case for both -moz-linear-gradient and -moz-radial-gradient.
OS: Mac OS X → All
Attached image screenshot
Top rendering of test case in WebKit
Bottom: Minefield latest, OS X.
So the real bug is that repeating gradient images aren't repeated left or top of the background origin, right?
(In reply to comment #2)
> So the real bug is that repeating gradient images aren't repeated left or top
> of the background origin, right?
Yes.
Assignee: nobody → roc
Attached patch fix (obsolete) — Splinter Review
Attachment #421173 - Flags: review?(dbaron)
Whiteboard: [needs review]
Comment on attachment 421173 [details] [diff] [review]
fix

I presume the old code would have been fine if integer division did round-down rather than round-towards-zero?  (i.e., that's what this is fixing)

>+static nscoord
>+FindTileStart(nscoord aDirtyCoord, nscoord aTilePos, nscoord aTileDim)
>+{
>+  NS_ASSERTION(aTileDim > 0, "Non-positive tile dimension");
>+  nscoord delta = aDirtyCoord - aTilePos;
>+  if (delta >= 0) {
>+    // delta is the offset from the left edge of the tile to aDirtyCoord
>+    return aDirtyCoord - (delta % aTileDim);
>+  }
>+  // Let delta be the offset from aDirtyCoord to the right edge of the tile
>+  delta = aTilePos + aTileDim - aDirtyCoord;
>+  return aDirtyCoord - (delta % aTileDim);

Seems like the "+ aTileDim" doesn't do anything (given that you % by aTileDim), so this line could just be "delta = -delta".  Which means the whole thing could simplify to:
  NS_ASSERTION(aTileDim > 0, "Non-positive tile dimension");
  nscoord delta = PR_ABS(aDirtyCoord - aTilePos);
  return aDirtyCoord - (delta % aTileDim);
But that doesn't actually make sense.

Perhaps this makes more sense:
  nscoord delta = (aDirtyCoord - aTilePos) % aTileDim
  if (delta < 0) {
    delta += aTileDim;
  }
  return aDirtyCoord - delta;
though I'm not sure.
Attachment #421173 - Flags: review?(dbaron) → review-
Attached patch fix v2Splinter Review
Oops, I shouldn't have chosen a test border-width that's exactly half a tile!

The easy way to do this is using floating point and NS_floor.
Attachment #421173 - Attachment is obsolete: true
Attachment #421193 - Flags: review?(dbaron)
Comment on attachment 421193 [details] [diff] [review]
fix v2

r=dbaron, although it seems like there should be a clean way that doesn't involve going into floating point
Attachment #421193 - Flags: review?(dbaron) → review+
Whiteboard: [needs review] → [needs landing]
Duplicate of this bug: 539289
Hi, i also reported this bug (see comment #8). It contains another possible test case.

And is this one going to be fixed for firefox 3.6? I can't find that on top of this page...

Good luck,
Mark
http://hg.mozilla.org/mozilla-central/rev/945792408b2c
Status: NEW → RESOLVED
Closed: 13 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [needs landing]
(In reply to comment #10)
> http://hg.mozilla.org/mozilla-central/rev/945792408b2c

Does it makes sense to get this on the 1.9.2 branch ?
Flags: wanted1.9.2?
blocking2.0: --- → beta1
Priority: -- → P2
This fixes a rather serious bug in a new feature in 3.6 (CSS Gradients):  they don't work correctly underneath the top or left border (when the border is dotted/dashed, partially opaque, or transparent), and we should get it in for 3.6.2.
Comment on attachment 421193 [details] [diff] [review]
fix v2

We missed 1.9.2.2.  Moving approval request forward.
Attachment #421193 - Flags: approval1.9.2.2? → approval1.9.2.3?
Comment on attachment 421193 [details] [diff] [review]
fix v2

a=LegNeato for 1.9.2.5. Please ONLY land this on mozilla-1.9.2 default, as we
are still working on 1.9.2.4 on the relbranch
Attachment #421193 - Flags: approval1.9.2.4? → approval1.9.2.5+
Landed on 1.9.2 by transplanting from mozilla-central:
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/d90854e79525
You need to log in before you can comment on or make changes to this bug.