672167 - Border on tr element "bleeds" to subsequent trs

Status: UNCONFIRMED

(Core :: Layout: Tables, defect)

Description

[marcin.tustin]

Attachment: Screenshot showing erroneous rendering.

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20100101 Firefox/5.0
Build ID: 20110615151330

Steps to reproduce:

Loaded a page with a border specified on a tr (full description, with formatted code and screenshot at stackoverflow: http://stackoverflow.com/questions/6731044/firefox-bleeding-borders-on-tr-bug)


Actual results:

The tr in question has a border, but there are also side borders on subsequent TRs. Interesting to note that this syndrome disappears if the zoom level is changed, and does not return until the page is reloaded.


Expected results:

There should only have been a border on the one tr for which it was specified.

Comment 1

[marcin.tustin]

Attachment: Zip file (generated by windows explorer) containing html showing the problem + supporting files (css etc)

Comment 2

[Mats Palmgren (inactive)]

The attached test works for me in Firefox 5 on Windows 7 and Linux.
It works also in Firefox 8.0a1 of recent date.
At some zoom levels the red border is thicker on one side than the other
sides, or one side completely missing.  I think that's a known bug.
I don't see any bleeding like in your screenshot though.

Can you reproduce the problem in Firefox Safe Mode?
http://support.mozilla.com/en-US/kb/Safe%20Mode

Comment 3

[Ivan]

Attachment: test case

I have the same problem in firefox 10.0.2 on Ubuntu 11.10 x32.
Bug reproduces in safe mode.

In test case attached:
1. push "add"
2. push "delete" in last row

"border-collapse" is important.

Comment 4

[marcin.tustin]

Ivan's testcase works for me, in that as soon as I add rows, the borders are of different thicknesses; pushing the delete button will leave gaps in the border.

(In reply to Ivan from comment #3)
> Created attachment 600861 [details]
> test case
> 
> I have the same problem in firefox 10.0.2 on Ubuntu 11.10 x32.
> Bug reproduces in safe mode.
> 
> In test case attached:
> 1. push "add"
> 2. push "delete" in last row
> 
> "border-collapse" is important.

Comment 5

[Ivan]

Attachment: Screenshot of test case.

Border should be only on the first row.

Comment 6

[Matthieu Rivaud]

Would this be remotely related to bug #714781 ?

Comment 7

[j.j.]

This needs a testcase without external references (read: without jQuery)

Comment 8

[j.j.]

(and is attachment 600861 [details] related to the original issue at all?)

Comment 9

[Ivan]

Attachment: minimal one without jQuery

Gives me the same result.

Comment 10

[Matthieu Rivaud]

I think it is the same bug as bug #714781 : the bleeding borders disappear if you scroll or reduce the window to hide the cell (and enlarge it back). Moreover, the confirm being needed to make the bug non intermittent is probably due to the repaint being triggered after the dialog is dismissed (setting the background color like in attachment 585674 [details] would probably suffice).

Comment 11

[Matthieu Rivaud]

Mmm. It seems like in attachment 601318 [details], the border can sometimes extend even further when scrolling, or reduce+enlarge the window ...