Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060922 Minefield/3.0a1 Steps to reproduce: 1. Open a browser window and hit Ctrl+T about 5-10 times until you see the lines appear on tabs. Bug 347482 tracked this issue when the new theme landed on branch, and it was supposedly fixed by bug 350139.

not just linux windows too

I see something similar under windows (see http://img141.imageshack.us/img141/6854/screenshot001by8.png) Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060922 Minefield/3.0a1 ID:2006092205 [cairo] -> PC / All ?

on the branch, I worked around this opacity issue with images with built in opacity. looking at the css on the trunk, we don't have the opacity rules, but it would be worth double checking with DOMi to see if there is any opacity coming from somewhere else. see bug #347482 for some history about this problem.

This is what I see: The transparency is inside of the images only. The boxes are positioned correctly, but some the left and right background images are shifted by 1px to the right. On the right side of the tab, this results in an uncovered line (that's -moz-dialog). On the left side of the tab, the image overlays the middle part (which shouldn't be possible).

Looks like border-radius is causing this. I've just experienced the same behavior while playing with my website's CSS.

I'd say this needs to be moved to Core.

btw, I can't reproduce this with Gecko 1.8. I wonder if this problem is related to bug 347482 at all.

Resizing the window makes the problem come and go. The involvement of margin makes me think this depends on bug 177805.

dao, thanks for that reduced test case. > btw, I can't reproduce this with Gecko 1.8. I wonder if this problem is related > to bug 347482 at all. I can't either, so I think you are right. > I'd say this needs to be moved to Core. I'll move it to core.

(In reply to comment #9) > The involvement of margin makes me think this depends on bug 177805. Here's a summary for different margin-left values (all using -moz-border-radius): 0 works 10px works 1em works 10.5px fails .6em fails

dao, with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070204 Minefield/3.0a2pre, I still see this (depending on the size of my window.) try this: javascript:top.resizeTo(1245,400); then load https://bugzilla.mozilla.org/attachment.cgi?id=240925

Yes, it still occurs when document.documentElement.clientWidth in attachment 240925 [details] is even.

Apparently bug 177805 made this worse. The with-border-radius case (without margin-left) in attachment 240925 [details] fails now.

Should investigate whether bug 371434 fixes this.

(In reply to comment #15) > Should investigate whether bug 371434 fixes this. It didn't so far. Note that the image in the testcase doen't really look scaled and that there's also a background color.

the only difference here is margin left is .6 (gap) vs .7 (no gap)

this screen shot comes from my Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070313 Minefield/3.0a3pre build.

-> both boxes (or their backgrounds only?!) are cut off

(In reply to comment #19) > -> both boxes (or their backgrounds only?!) are cut off ... not really cut off, as the rounded edge on the right is still intact.

With my default font-size I see the gap in the lower box. Try changing font-sizes (Ctrl++, Ctrl+-) and see how the gaps change every time. Isn't this a px vs em unit problem? Mixing px and em is a really bad idea in general.

> With my default font-size I see the gap in the lower box. > Try changing font-sizes (Ctrl++, Ctrl+-) and see how the gaps change every > time. I see the same thing, thanks for pointing that out Arpad. > Isn't this a px vs em unit problem? Mixing px and em is a really bad idea in > general. I'll leave that question and comment for roc to answer.

(In reply to comment #21) > Isn't this a px vs em unit problem? It's obviously related to em, but that doesn't mean that any of the test cases should fail. As you can see in attachment 259225 [details], width:42px for .a is violated as well as width:8px for .b. > Mixing px and em is a really bad idea in general. As long as you know what you're doing and as long as the rendering engine isn't broken ;), it's not a bad idea at all.

Ah, ok, so what's different about border-radius is that you're going through nsCSSRendering::PaintRoundedBackground instead of nsCSSRendering::PaintBackgroundColor, which means you get a FillPolygon instead of a FillRect. So that probably means this is the same underlying problem as bug 363220. I should probably add tests that stress PaintRoundedBackground to layout/reftests/pixel-rounding/, at least if vlad's not eliminating it in his border rewrite.

I checked in a bunch of tests for this, although they're all currently marked as random until I can evaluate their state on various platforms.

This is fixed by the patch in bug 379505; the testcases seem to work, and there's no more cruft in the tabbar. The main underlying issue is that the rectangle that's given in the border radius case was: x: 6000 y: 30 width: 6000: height: 120 -- 60 twips/pixel, so that's 100, 0.5 and 100x2 So the rectangle that was being rendered wasn't pixel aligned, and so there was visible fringing. I think that beforehand, the mechanism that was being used to render the approximated rounded rectangle wasn't getting rounded by by thebes rendering context wrapper.

I just landed a partial fix for this with the patch in bug 379505; however, things seem shifted down by 1px, and I'm not sure if that's still this bug or another. Adding margin-bottom: 1px ! important makes everything look like Fx2. Not sure if this bug should be closed or not.

(In reply to comment #28) > I just landed a partial fix for this with the patch in bug 379505; however, > things seem shifted down by 1px, and I'm not sure if that's still this bug or > another. It's bug 369882.

Ok; marking this as passing -- the reftests that were marked as failing due to this bug are also passing now.