gradient(s) not painted correctly in border-edge

RESOLVED FIXED

Status

()

Core
CSS Parsing and Computation
P2
normal
RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: philippe (part-time), Assigned: roc)

Tracking

Trunk
x86
All
Points:
---
Bug Flags:
wanted1.9.2 ?
in-testsuite +

Firefox Tracking Flags

(blocking2.0 beta1+, status1.9.2 .5-fixed)

Details

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

8 years ago
Created attachment 420992 [details]
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.
(Reporter)

Updated

8 years ago
OS: Mac OS X → All
(Reporter)

Comment 1

8 years ago
Created attachment 420993 [details]
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?
(Reporter)

Comment 3

8 years ago
(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
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-
Created attachment 421193 [details] [diff] [review]
fix v2

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

Comment 9

8 years ago
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
Last Resolved: 8 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [needs landing]
(Reporter)

Comment 11

8 years ago
(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 14

8 years ago
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
status1.9.2: --- → .5-fixed
You need to log in before you can comment on or make changes to this bug.