347482 - Visual refresh leaves vertical lines in some tabs

Status: RESOLVED FIXED

(Firefox :: General, defect)

Description

[Mark Mentovai]

I have found that certain tab widths that are large enough to display the close box leave vertical lines to the left of the close box in some tabs when in the background or hovered.  I have yet to experience this in foreground tabs.  I have also not experienced it at the default (full) tab width.

To reproduce: begin opening new tabs until the tab strip is full, and then keep opening new tabs.  You'll eventually see the problem.  If you get far enough for the close boxes disappear, you'll have gone too far.  Go back and try again with a different window width.

(As initially reported in bug 347468 comment 1.)

Comment 1

[Mark Mentovai]

Attachment: Demonstration of the vertical line

The second tab (hovered) and fourth tab (background) show the unwanted vertical line.

Comment 2

[Mike Beltzner [:beltzner, not reading bugmail]]

Definitely something we want to fix; any idea what's causing it?

Comment 3

[Peter Kasting]

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

Comment 4

[Peter Kasting]

Now that the tab strip has been checked in for Winstripe this bug is present there as well.  See screenshot in https://bugzilla.mozilla.org/attachment.cgi?id=234139 (on bug 348951, duped against this).

Comment 5

[Pardal Freudenthal (:ShareBird)]

Maybe this can help. I use on my theme similar technique like the default theme is using now to design the tabs (a left, a middle and a right part) with the difference I have placed all the stuff (close button, favicons, etc.) inside the middle part. I have noticed this problem with my theme on Firefox 1.0 but not on Firefox 1.5 at all.

I've solved the problem giving an 1px negative margin to the middle part.

This works also on this case. I did:

.tabbrowser-tab > .tab-image-middle {
  -moz-margin-end: -1px;
}

Comment 6

[(not reading, please use [e-mail] instead)]

mike, something that I noticed that might help figure this one out.

When I hit this bug, if I set the opacity of the tab-image-middle and tab-image-right to 1.0, the problem goes away.  (This explains why it doesn't show up in the selected tab.  For non-selected tabs, the opacity of those elements is 0.6.)

mike, isn't the plan to use background images that have the opacity built in?  if so, that might work around this bug for us.

that said, I think there is a legitimate bug lurking here.

> .tabbrowser-tab > .tab-image-middle {
>  -moz-margin-end: -1px;
>}

fwiw, pardal's trick also works around the problem for me.

Comment 7

[Mike Beltzner [:beltzner, not reading bugmail]]

--> seth, per mconnor

This should be fixed by bug 350139.

Comment 8

[(not reading, please use [e-mail] instead)]

to reproduce, use javascript:window.resizeTo(888,9999); and then have open exactly blank tabs. (thanks to mark for this trick)

I've confirmed that the new images (without opacity) fixes this issue.

Comment 9

[(not reading, please use [e-mail] instead)]

I have landed some new images and css changes to "fix" this on winstripe.

the underlying bug is still there, but since we are not using opacity like we were, the bug isn't showing up.

in addition to making a similar "fix" for pinstripe, it would be good to narrow down the underlying bug into a simple test case (and to check the trunk as the trunk has some fixes for views + opacity that the branch does not have.)

Comment 10

[(not reading, please use [e-mail] instead)]

> I have landed some new images and css changes to "fix" this on winstripe.

...as part of bug #350139, I meant to add.

Comment 11

[(not reading, please use [e-mail] instead)]

fixed on pinstripe, too (with the landing of the images and css from bug #350139).

but I'll log a spin off bug on real issue, which is still there.  (but it may not be on trunk, as view / opacity issues have improved there, thanks to roc)

Comment 12

[(not reading, please use [e-mail] instead)]

> but I'll log a spin off bug on real issue, which is still there.  (but it may
> not be on trunk, as view / opacity issues have improved there, thanks to roc)

I still need to log a spin off bug and create a simplified test case.

but note, the issue is back on the trunk:  see bug #353860

Comment 13

[(not reading, please use [e-mail] instead)]

> but note, the issue is back on the trunk:  see bug #353860

note, it is back on the trunk, but it appears to be for a different reason. 

dao has a test case in that bug, but it has nothing to do with opacity.