Last Comment Bug 24998 - background images spill beyond rounded borders / -moz-border-radius
: background images spill beyond rounded borders / -moz-border-radius
Status: VERIFIED FIXED
: css-moz, perf, relnote, testcase
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: All All
: P3 normal with 17 votes (vote)
: mozilla1.9beta3
Assigned To: Vladimir Vukicevic [:vlad] [:vladv]
:
Mentors:
http://www.damowmow.com/playground/bu...
: 55650 211094 230755 234823 276083 (view as bug list)
Depends on: 468314
Blocks: 359568 387345
  Show dependency treegraph
 
Reported: 2000-01-25 11:23 PST by Hixie (not reading bugmail)
Modified: 2008-12-07 03:54 PST (History)
51 users (show)
mtschrep: blocking1.9+
rflint: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Testcase (1.15 KB, text/html)
2002-01-06 19:09 PST, Christopher Aillon (sabbatical, not receiving bugmail)
no flags Details
patch (2.59 KB, patch)
2007-09-06 14:24 PDT, Vladimir Vukicevic [:vlad] [:vladv]
no flags Details | Diff | Splinter Review
Fixed TestCase (1.27 KB, text/html)
2007-11-29 18:57 PST, Biju
no flags Details
slightly updated patch (2.56 KB, patch)
2007-12-02 12:29 PST, Vladimir Vukicevic [:vlad] [:vladv]
roc: review+
roc: superreview+
Details | Diff | Splinter Review
Displays non-clipping of background images (3.25 KB, text/html)
2008-02-14 01:00 PST, Nicholas Shanks
no flags Details
Fixed testcase: div with background image to inherit border-radius (3.38 KB, text/html)
2008-02-14 01:24 PST, Alfred Kayser
no flags Details

Description Hixie (not reading bugmail) 2000-01-25 11:23:58 PST
This broke out of bug 23704. Background images are not clipped to the rounded 
border. See the first part of this test case:
   http://www.bath.ac.uk/%7Epy8ieh/m/border-radius-image.html   

[assigning straight to dcone, to avoid the pierre|troy -> rods -> dcone route
these bugs normally take...]

The following comments were by german on bug 23704.

------- Additional Comments From german@netscape.com  2000-01-25 10:33 -------
In case somebody wonders we will need this to complete the transition for the 
default skin from using fake bitmaps for radii towards using 'real' 
stylesheets. Desirable time frame for a fix would be m14, in order to get it 
into a potntial beta candidate.
Comment 1 Hixie (not reading bugmail) 2000-01-25 11:26:25 PST
Giving QA to chrisd as with bug 23704.
Comment 2 dcone (gone) 2000-01-27 09:41:14 PST
Talked with RickG, this will not be supported.  The biggest problem is Linux 
does not support regions for clipping.  
For UI, can GIF's with transparency work here?
Comment 3 Christine Hoffman 2000-02-01 11:48:27 PST
Verifying REMIND. If anyone has objections, please reopen.
Comment 4 John Morrison 2000-10-14 19:41:14 PDT
*** Bug 55650 has been marked as a duplicate of this bug. ***
Comment 5 Hixie (not reading bugmail) 2000-10-15 07:37:43 PDT
Reopening and moving to Future...
Comment 6 Robert Kaiser 2000-10-15 08:05:49 PDT
For a simple XUL testcase of this, see bug 55650.
BTW, it turns out that also background color spills out of the rounded border if 
any (even non-existent) background-image is assigned, and this is one of my 
biggest problems with skin work right now...
Would be nice to get this fixed after focus of NS people is off RTM (perhaps 
target mozilla1.0 then). I hope there'll be some possibility to deal with that 
Linux problem...
Comment 7 Hixie (not reading bugmail) 2001-02-12 16:26:42 PST
Netscape's standard compliance QA team reorganised itself once again, so taking 
remaining non-tables style bugs. Sorry about the spam. I tried to get this done 
directly at the database level, but apparently that is "not easy because of the 
shadow db", "plus it screws up the audit trail", so no can do...
Comment 8 Christopher Aillon (sabbatical, not receiving bugmail) 2002-01-06 19:09:39 PST
Created attachment 63769 [details]
Testcase

Here's another testcase which also shows the background color spilling out even
if there is a broken background image.
Comment 9 Adam Fletcher 2002-05-02 08:05:18 PDT
This has my vote - this is affecting me, as I want to put a background image on
tab's but cant because of this bug.  Anyone have a status?
Comment 10 Hixie (not reading bugmail) 2002-05-02 15:42:27 PDT
I doubt this will get worked on by any of the layout people until after CSS3 has
a border-radius equivalent.
Comment 11 Christian Eyrich 2003-07-01 03:22:47 PDT
*** Bug 211094 has been marked as a duplicate of this bug. ***
Comment 12 Christopher Aillon (sabbatical, not receiving bugmail) 2004-01-12 16:41:05 PST
*** Bug 230755 has been marked as a duplicate of this bug. ***
Comment 13 José Jeria 2004-02-18 15:22:47 PST
*** Bug 234823 has been marked as a duplicate of this bug. ***
Comment 14 Colin Snover 2005-01-04 19:50:15 PST
Bump, comment #10 indicated that this would not be worked on until CSS3 had a
border-radius property. It has since (at least) 2002-11-07, so I guess work can
be started on fixing this bug, right?
http://www.w3.org/TR/2002/WD-css3-border-20021107/#the-border-radius

I'd like to see some headway made (I'd like to do it myself, but there are a
couple factors limiting this: time and ability. :))
Comment 15 Boris Zbarsky [:bz] 2005-01-25 21:57:59 PST
*** Bug 276083 has been marked as a duplicate of this bug. ***
Comment 16 Kae Verens 2005-03-31 01:08:33 PST
There are some differences between border-radius (the W3C proposal) and
-moz-border-radius, which may cause backwards-compatibility conflicts.

I am willing to put time into matching the W3C proposal (which I expect will
become a recommendation).

Should I bother, or is the potential incompatibility unwelcome at this time?

If it's welcome, then I'd like to discuss some ideas on how to implement it.
Comment 17 Kae Verens 2005-04-03 13:37:06 PDT
a solution to the spilling might be to tile the background images as normal,
then remove the curves from the corners by painting them in a transparent colour.

Here is some code to do the painting. It paints in a solid colour, as I can't
seem to get alpha-values working. Place this code at the end of
PaintBackgroundWithSC() in nsCSSRendering.cpp :

  static nsPoint   polypath[MAXPOLYPATHSIZE];
  PRInt32       curIndex,c1Index;
  nsFloatPoint  aPoints[MAXPATHSIZE];
  PRInt16 borderRadii[4];
  nsStyleCoord bordStyleRadius[4];
  QBCurve       cr1,cr2;
  QBCurve       UL;
  UL.MidPointDivide(&cr1,&cr2);
  aBorder.mBorderRadius.GetTop(bordStyleRadius[NS_SIDE_TOP]);       // topleft
  aBorder.mBorderRadius.GetRight(bordStyleRadius[NS_SIDE_RIGHT]);   // topright
  aBorder.mBorderRadius.GetBottom(bordStyleRadius[NS_SIDE_BOTTOM]); // bottomright
  aBorder.mBorderRadius.GetLeft(bordStyleRadius[NS_SIDE_LEFT]);     // bottomleft
  PRUint8 side = 0;
  for (; side < 4; ++side) {
    borderRadii[side] = 0;
    switch (bordStyleRadius[side].GetUnit()) {
      case eStyleUnit_Percent:
        borderRadii[side] = nscoord(bordStyleRadius[side].GetPercentValue() *
bgClipArea.width);
        break;
      case eStyleUnit_Coord:
        borderRadii[side] = bordStyleRadius[side].GetCoordValue();
        break;
      default:
        break;
    }
  }
  aRenderingContext.SetColor(NS_RGBA(255,255,255,127));
  for (side=0; side < 4; ++side) {
    if(borderRadii[side]>0){
      switch (side) {
        case 0:
          aPoints[0].x=borderRadii[0];
          aPoints[0].y=0;
          aPoints[1].x=cr2.mCon.x;
          aPoints[1].y=cr2.mCon.y;
          aPoints[2].x=0;
          aPoints[2].y=borderRadii[0];
          aPoints[3].x=0;
          aPoints[3].y=0;
          break;
        case 1:
          aPoints[0].x=aBorderArea.width-borderRadii[1];
          aPoints[0].y=0;
          aPoints[1].x=aBorderArea.width-cr2.mCon.x;
          aPoints[1].y=cr2.mCon.y;
          aPoints[2].x=aBorderArea.width;
          aPoints[2].y=borderRadii[1];
          aPoints[3].x=aBorderArea.width;
          aPoints[3].y=0;
          break;
        case 2:
          aPoints[0].x=aBorderArea.width-borderRadii[2];
           aPoints[0].y=aBorderArea.height;
          aPoints[1].x=aBorderArea.width-cr2.mCon.x;
          aPoints[1].y=aBorderArea.height-cr2.mCon.y;
          aPoints[2].x=aBorderArea.width;
          aPoints[2].y=aBorderArea.height-borderRadii[2];
          aPoints[3].x=aBorderArea.width;
          aPoints[3].y=aBorderArea.height;
          break;
        case 3:
          aPoints[0].x=borderRadii[3];
          aPoints[0].y=aBorderArea.height;
          aPoints[1].x=cr2.mCon.x;
          aPoints[1].y=aBorderArea.height-cr2.mCon.y;
          aPoints[2].x=0;
          aPoints[2].y=aBorderArea.height-borderRadii[3];
          aPoints[3].x=0;
          aPoints[3].y=aBorderArea.height;
      }
      polypath[0].x = NSToCoordRound(aPoints[0].x);
      polypath[0].y = NSToCoordRound(aPoints[0].y);
      curIndex = 1;
      GetPath(aPoints,polypath,&curIndex,eOutside,c1Index);
      polypath[curIndex].x = NSToCoordRound(aPoints[3].x);
      polypath[curIndex].y = NSToCoordRound(aPoints[3].y);
      curIndex++;
      polypath[curIndex].x = NSToCoordRound(aPoints[0].x);
      polypath[curIndex].y = NSToCoordRound(aPoints[0].y);
      curIndex++;
      aRenderingContext.FillPolygon(polypath,curIndex);
    }
  }
Comment 18 Robin Whittleton 2005-10-06 06:03:09 PDT
This also applies when you try to apply -moz-border-radius to a normal <img>
element (with no background-image set). The border goes underneath the image in
this case though, as opposed to above the image as in the earlier testcase.
Comment 19 John Mellor (Jomel) 2006-03-11 17:03:34 PST
(In reply to comment #18)
> This also applies when you try to apply -moz-border-radius to a normal <img>
> element (with no background-image set). The border goes underneath the image in
> this case though, as opposed to above the image as in the earlier testcase.

That seems correct, border-radius isn't supposed to clip the content or anything.
It would be nice to get this fixed though.
Comment 20 Wesley Johnston (:wesj) 2006-04-19 11:06:50 PDT
May be a different bug, but text isn't fit into boxes with rounded borders correctly either. In that case it shouldn't be clipped though. It should just fit, ideally with different line widths depending on the box width at that point.

Test Page: http://public.wesleyjames.fastmail.fm/test.html
(I won't upload it, as I think this is the wrong bug, but can't find a more suitable one, and don't want to create a possible dupe yet)
Comment 21 fantasai 2007-01-22 03:14:38 PST
roc says it should be possible to fix this with Cairo.
Comment 22 Zibi Braniecki [:gandalf][:zibi] 2007-06-19 12:41:59 PDT
reproduced in today's trunk on Linux with Cairo
Comment 23 Vladimir Vukicevic [:vlad] [:vladv] 2007-06-19 13:11:35 PDT
Yeah, the fix for this is fairly easy, it's just been low on my list because it's not a regression.  Assigning to me, if I ever get under my pile of blockers...
Comment 24 Zibi Braniecki [:gandalf][:zibi] 2007-06-19 13:50:02 PDT
for the sake of human history:

<vlad> gandalf: so the cheap and easy fix is to just set a clip before we draw the image
<vlad> and you can set the clip by calling some of the new methods to calculate the outer radius
<vlad> e.g. see what the rounded border background solid color thing does
<vlad> to create the path
<vlad> and then jsut do that and call Clip() instead of fill
<vlad> and then do the image drawing
<vlad> that should basically do it


<vlad> gandalf: the long-term fix is whack PaintBackground to draw stuff using thebes directly.. I started doing that a while ago but had to abandon it
<vlad> gandalf: not in a bug
<vlad> don't worry about that, I think doing the clip thing should get that particular thing working
<vlad> and should be good enough for 1.9

I'll try the cheap and easy way... ;)
Comment 25 Vladimir Vukicevic [:vlad] [:vladv] 2007-08-22 22:57:57 PDT
Just noticed -- in the testcase, on the second chunk with the background image, there's an invalidation issue -- if you highlight text in the upper left or upper right corners and then unhighlight, the text/background doesn't get repainted correctly.
Comment 26 Robin Whittleton 2007-08-22 23:45:47 PDT
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a8pre) Gecko/2007082004 Minefield/3.0a8pre

I'm not seeing that particular issue on Mac. OS-specific?
Comment 27 Jesse Ruderman 2007-08-25 21:51:54 PDT
Adding "perf" keyword based on rumors that Firefox UI could use fewer DOM elements if this were fixed.
Comment 28 Vladimir Vukicevic [:vlad] [:vladv] 2007-08-26 01:13:57 PDT
Tabs, in particular, could be significantly changed (to a single box, even, where now there are 4 or more) using a combination of this and bug 378217 (border-image)... I think either one would be sufficient, border-image might be more efficient (faster to draw images), but using true borders would let us scale the UI and have it look nice.
Comment 29 Vladimir Vukicevic [:vlad] [:vladv] 2007-09-06 14:24:57 PDT
Created attachment 279977 [details] [diff] [review]
patch

Ok, I took a bit to whip up this patch; it was even simpler than I thought.  This seems to work, at least for the few testcases that I tried.  There's some unnecessary code duplication, and as I said before, PaintBackground really needs to be completely redone, but that's not going to happen for 1.9.
Comment 30 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2007-09-12 17:56:05 PDT
+  nsRefPtr<gfxContext> ctx = (gfxContext*)

static_cast

+  ctx->Rectangle(RectToGfxRect(dirtyRect, appUnitsPerPixel));

The old code used to snap with PR_TRUE here (in SetClipRect), now you're not spanning. I think you should, the performance hit of non-pixel-aligned cliprects is horrific.

+        borderRadii[side] = nscoord(bordStyleRadius[side].GetPercentValue() *
+                                    aForFrame->GetSize().width);

Why use the width for all four sides?

Maybe this is the wrong time to ask, but is there a reason this code can't just call aForFrame->GetUsedBorder? Is aBorder possibly not the frame's real border?
Comment 31 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2007-09-17 16:45:57 PDT
Comment on attachment 279977 [details] [diff] [review]
patch

Cancelling request pending comments being addressed
Comment 32 Vladimir Vukicevic [:vlad] [:vladv] 2007-11-14 18:25:37 PST
(In reply to comment #30)
> +  nsRefPtr<gfxContext> ctx = (gfxContext*)
> 
> static_cast

The previous uses of this in the file did c-style casts; I can replace them all with static_cast<>

> +  ctx->Rectangle(RectToGfxRect(dirtyRect, appUnitsPerPixel));
> 
> The old code used to snap with PR_TRUE here (in SetClipRect), now you're not
> spanning. I think you should, the performance hit of non-pixel-aligned
> cliprects is horrific.

Will do.

> +        borderRadii[side] = nscoord(bordStyleRadius[side].GetPercentValue() *
> +                                    aForFrame->GetSize().width);
> 
> Why use the width for all four sides?
> 
> Maybe this is the wrong time to ask, but is there a reason this code can't just
> call aForFrame->GetUsedBorder? Is aBorder possibly not the frame's real border?

This is what the border code has done in the past (and is done elsewhere) -- percentages are always relative to the width of the element (since as far as I understand it, CSS layout only deals with widths as input).  GetUsedBorder returns the border sizes themselves, right?  Not sure where it'd be used here
Comment 33 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2007-11-14 19:45:20 PST
oops, you're right.
Comment 34 Mike Schroepfer 2007-11-23 10:37:35 PST
Adding to blocking list based on Comment 28 as a way to improve perf..
Comment 35 Biju 2007-11-29 18:57:55 PST
Created attachment 290809 [details]
Fixed TestCase

border_radius_spil.html
Comment 36 Vladimir Vukicevic [:vlad] [:vladv] 2007-12-02 12:29:40 PST
Created attachment 291099 [details] [diff] [review]
slightly updated patch

Does snap for clipping to dirtyRect; I didn't do the static_cast change because I want to get rid of NATIVE_THEBES_CONTEXT entirely and just add a aRenderingContext.ThebesContext() call everywhere.
Comment 38 Vladimir Vukicevic [:vlad] [:vladv] 2007-12-18 13:01:13 PST
Checked in; changed Ryan's reftests slightly to be closer to what I had in my tree (mainly, need to use a 2x2 image to avoid some 1x1 optimizations that could affect the result).
Comment 39 Jesse Ruderman 2007-12-18 13:51:11 PST
Should there be reftests covering the 1x1 case as well?
Comment 40 alta88 2007-12-19 13:23:00 PST
if this is intended to fix chrome also, it doesn't seem to.  overflow is still there in urlbar using:

textbox, filefield {
    -moz-appearance: none !important;
    -moz-border-radius: 14px !important;
    padding-right: 8px !important;
    padding-left: 4px !important; 
}

in addition <filefield> doesn't work at all.

the content testpage in #35 does work.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2007121905 Minefield/3.0b3pre ID:2007121905
Comment 41 Vladimir Vukicevic [:vlad] [:vladv] 2007-12-21 12:39:39 PST
(In reply to comment #40)
> if this is intended to fix chrome also, it doesn't seem to.  overflow is still
> there in urlbar using:

I'm not sure what you mean here; can you provide a full testcase, or at least screenshots of what's happening and what you'd expect?
Comment 42 alta88 2007-12-22 06:49:28 PST
?

simply put the css, with the xul namespace, in your userchrome.css file, and restart (i use the stylish extension to easier apply changes).  the chrome elements' background overflows at the corners; a <filefield> is a type of <textbox> and is found, for one, in Options -> Main (Downloads groupbox - Save files box) - its border disappears completely with moz-border-radius.

i would expect this background overflow fix to also apply to chrome elements borders.  is this fix intended to apply to chrome element borders?

here's the entire userchrome.css for completeness:

@namespace url(http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul);

menulist, textbox, filefield {
    -moz-appearance: none !important;
    -moz-border-radius: 14px !important;
    padding-right: 8px !important;
    padding-left: 4px !important; 
}
Comment 43 Biju 2007-12-24 14:42:18 PST
There is still an issue with actual text content inside the box,
please see bug 409547.
Comment 44 Alfred Kayser 2008-02-04 07:45:29 PST
There is also still an issue in combination with -moz-border-*-colors: see bug 414545. The strange thing is that with background-image it works correctly, but not with just background-image.
Comment 45 Eric Shepherd [:sheppy] 2008-02-13 15:13:01 PST
Someone suggested that this is something that should be mentioned in docs, but reading quickly over the comments here and glancing at the patch, I don't see anything obvious that stands out as needing to be documented per se.  Anyone want to pitch in what I should say if anything in the moz-border-radius doc?
Comment 46 fantasai 2008-02-13 15:38:43 PST
I think it just needed to be added to the "new for FF3" notes.
Comment 47 Nicholas Shanks 2008-02-14 00:58:19 PST
This bug is not fixed and needs to be reopened. I have provided an extension to the test case at http://web.nickshanks.com/browsers/mozilla/border-radius-image which demonstrates this (and attached it to the bug).
Comment 48 Nicholas Shanks 2008-02-14 01:00:38 PST
Created attachment 303228 [details]
Displays non-clipping of background images
Comment 49 Alfred Kayser 2008-02-14 01:20:34 PST
This test case is not valid. 
Rounding of 'background-image' only happens if on the *same* element, the border-radius is specified. 
The simple thing to do to get this effect is to replace:
   div.bkgnd div div {width: 7em; height: 7em; background: url('http://www.hixie.ch/resources/images/sample.gif'); }
with:
   div.bkgnd div div { -moz-border-radius:inherit; width: 7em; height: 7em; background: url('http://www.hixie.ch/resources/images/sample.gif'); }

So that the div with the background image has the same radius as its parent.
Comment 50 Alfred Kayser 2008-02-14 01:24:52 PST
Created attachment 303232 [details]
Fixed testcase: div with background image to inherit border-radius

So, no need to re-open the background image clipping is now as it should be.
Comment 51 Henrik Skupin (:whimboo) 2008-02-14 01:29:09 PST
Indeed. I can verify that it is fixed with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008021104 Minefield/3.0b4pre ID:2008021104 and the latest test case from Alfred. Background images are cropped correctly.
Comment 52 alta88 2008-02-14 07:01:10 PST
this bug is not fixed, per comments 40 and 42.
Comment 53 Alfred Kayser 2008-02-14 07:34:49 PST
Background image/color rounding is ONLY applied when that same element has -moz-border-radius set. The elements that 'fail' to round in comment #40 and #42 are child elements which don't have border-radius set.
You have to explicitly set the -moz-border-radius on those elements as well, like so:

@namespace url(http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul);

menulist, textbox, filefield {
    -moz-appearance: none !important;
    -moz-border-radius: 14px !important;
    padding-right: 6px !important;
    padding-left: 2px !important; 
}

#identity-box,.searchbar-engine-button{
    -moz-border-radius: 12px !important;
}

You will also need to this for the other child elements in textbox which apply background color and/or image.
Comment 54 alta88 2008-02-14 08:56:28 PST
thanks alfred.  yes, it's clear children need this explicitly applied in a complex box like urlbar.  but i'm talking about the background-color or background-image, which are properties of <textbox> and not children.  these overflow and they should not.  i mean, it works that way for content, no?

look at #search-box, the simplest <textbox>, in sidebar history eg.  how would you fix that?  and <filefield> just doesn't work - there is no border at all, that's simply broken afaict.
Comment 55 Alfred Kayser 2008-02-14 10:57:54 PST
Alta88, I suggest you take this discussion to another bug (or forum).
The issues you are facing are not because of the rendering, but the way the widgets are constructed and styled (which makes it not always easy to change something simple as the border).

To fix <filefield> do the following:
filefield{
    border:2px inset threedface!important;
    background-image:url("file:///c:/tmp/agif/1041385237.gif")!important;
    color:white!important;
}
.fileFieldContentBox{background:transparent none!important}

Note, this even works with animated gifs, rounding and all...
Comment 56 alta88 2008-02-15 07:54:30 PST
sorry, your suggestions are improper hacks and certainly not expected behavior.  i suggest you reread the title of the bug.  and to be forced to explicitly redefine an element's border because it is removed is simply ludicrous.  the issues i'm facing are because this 'fix' doesn't work for chrome, period.

perhaps it should be a separate bug, but the patch author hasn't responded whether it was intended for chrome despite being asked, therefore this remains the proper place. not wanting to reopen a bug doesn't actually fix it, btw.
Comment 57 Alfred Kayser 2008-02-15 08:01:08 PST
The original bug was reported on normal plain content rendering where the background-image did not follow the radius rounding of a border (-moz-border-radius). 

Whether filefield, textbox and other widgets work correctly or not is a separate subject. I would suggest to create new bugs for those widgets.

The patch did not remove borders, or change anything else. 
The only thing it did was to make sure that for an element the background-image is rounded according to the -moz-border-radius set on the same element.

Whether child elements also inherit the radius is yet again another topic, and possibly worth a new bug as well.
Comment 58 fantasai 2008-02-15 11:27:38 PST
border-radius is not an inherited property (per spec), so if you open a new bug on making -moz-border-radius inherit it would be marked INVALID. If the issue is widgets that are made up of a combination of boxes, you can open a bug on making the inner elements specify -moz-border-radius: inherit in the ua style sheet.
Comment 59 alta88 2008-02-16 09:59:48 PST
(In reply to comment #57)
> The original bug was reported on normal plain content rendering where the
> background-image did not follow the radius rounding of a border
> (-moz-border-radius). 
> 
> Whether filefield, textbox and other widgets work correctly or not is a
> separate subject. I would suggest to create new bugs for those widgets.
> 

per comments 4 and 6, the xul version of this bug was duped back to this bug.  so really, this bug is not fixed and should be reopened.

> The patch did not remove borders, or change anything else. 
> The only thing it did was to make sure that for an element the background-image
> is rounded according to the -moz-border-radius set on the same element.

i don't see how that's true.  adding -moz-border-radius to <filefield> causes the border to disappear.

please stop apologizing for this 'fix'.

Comment 60 alta88 2008-02-16 11:17:24 PST
the very recently checked in bug 359568 solves the <textbox> corner overflow portion of the problem here.
Comment 61 Alfred Kayser 2008-02-17 02:57:04 PST
> i don't see how that's true.  adding -moz-border-radius to <filefield> causes
> the border to disappear.
No, the line
    -moz-appearance: none !important;
makes it disappear. In the default theme the border of filefied (and other widgets) are drawn by the 'system appearance', using -moz-appearance: textfield.
By setting -moz-appearance: none one tells to Mozilla/Firefox to not do that, but that the border will be styled using normal css. As that widget doesn't have borders set, it won't therefor draw these. 

Regarding comments #4 and #6, and thus bug 55650: This is really solved because if now wants to apply a startrek image to an element and apply -moz-border-radius it will work. 

However, one has to take that child elements also have border-radius (see comment #55), that child elements or have no background fill (image or color), or that the also do rounding. See comment #58 why radius is not inherited by default (but one can always do -moz-border-radius: inherit.. 

please stop discussing this on this bug.
please create a new bug to address your issues.

Note You need to log in before you can comment on or make changes to this bug.