222402 - {inc}{quirks}Two identical (height:100%) elements rendered differently

Status: VERIFIED FIXED

(Core :: Layout: Tables, defect)

Description

[:aceman]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007 Firebird/0.7
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007 Firebird/0.7

I will attach a testcase later.

I suspect 2 problems here:
1. the combination of 'display: block' and 'vertical-align: middle' properties
makes all cells in the first column render incorrectly, except the first top
cell. Every time.
2. the 'border-collapse: collapse' rendering has problems and does not always
render all borders. This seems random and not happen all the time.
The borders also appear when the table is covered an then uncovered by another
application window.

Reproducible: Always

Steps to Reproduce:
1.See the attached testcase

Actual Results:  
1. The cells in the first column render differently although I don't see any
difference in the code.
2. Sometimes, some of the borders are missing. This is cured by subsequent
reloads of the page. Sometimes, the border-collapse: collapse property is
completely ignored and the cells are rendered with separate borders.

Expected Results:  
1. The cells should be visually identical. In my opinion, the top cell is correct.
2. The borders should be there and always the same in every reload of the file.

Comment 1

[:aceman]

Attachment: Code which shows the bug.

Comment 2

[:aceman]

Attachment: The file as rendered by Firebird 0.7

Comment 3

[:aceman]

Attachment: The same file in Firebird 0.7 after pressing reload.

Comment 4

[:aceman]

Attachment: The same file rendered by IE 5.5

I think this time IE got it right.

Comment 5

[:aceman]

I spotted this in Mozilla 1.3.1, but it is still there in today's latest Firebird.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Duplicate of bug 176237?

Comment 7

[Mats Palmgren (inactive)]

Attachment: Testcase 2

Comment 8

[Mats Palmgren (inactive)]

The missing borders is bug 176237.

Comment 9

[Mats Palmgren (inactive)]

FWIW, it works in Mozilla 1.0.2

Comment 10

[:aceman]

I don't think the mentioned bug is the same. That is about relatively positioned
inlines. This is about TABLE CELLS with border-collapse: collapsed. And this one
is still reproducible, whereas the bug 176237 testcase does not show any bug for
me. Of course, it would be better to file a separate bug for that. Should I do
that? And add a screenshot where the border-collapse is completely ignored at
some reloads?

This one is already specialized on the second problem. Thanks for the new
testcase and cleaning up the styles. I just pasted all rules into the file,
without testing, which one causes the problem.

Comment 9: do you think it is a regression? It worked but is broken now
(actually at least 2 releases long)?

Comment 11

[Mats Palmgren (inactive)]

Maybe bug 190593 fits the border problem better.  It's a known problem anyway.
I wouldn't call it a regression, 1.0.2 is too long ago.

Comment 12

[:aceman]

I knew that bug before I filed this one. They are a bit different. The testcase
in that bug renders consistently wrong for me. My bug and testcase renders
mostly right, just sometimes (randomly) it gets wrong. A reload of the page
fixes the problem. I.e. if you press F5 several times, you can always get
different rendering. If duping, bug 157047 seems most appropriate, but it is
fixed and it's testcases (url) don't work anymore, therefore I can't prove it. I
know collapsed borders are a known problem, but I couldn't find a bug for this
specific symptom.

Comment 13

[:aceman]

Interestingly, the testcases render correctly in the 'Print preview'...

Comment 14

[:aceman]

I can no longer reproduce this in FF 1.5, the testcases render correctly. Can anybody else? Otherwise I will close as WFM.

Comment 15

[Mats Palmgren (inactive)]

Attachment: Testcase 3 (same as Testcase 2 but in Quirks mode)

Comment 16

[Mats Palmgren (inactive)]

Testcase 3 still reproduces the bug in SeaMonkey 2005-12-15-01 trunk Linux.

Comment 17

[:aceman]

Firefox 1.5.0.1 too.

Comment 18

[Gábor Stefanik]

This bug, just like the most other incremental reflow bugs will go away when reflow refactoring lands. WFM in FiReflowfox (test build of Firefox from the reflow refactoring branch).

Comment 19

[Steve England [:stevee]]

"Code which shows the bug" and "Testcase 2" are rendered the same for me with:
- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/2006120606 Minefield/3.0a (pre-reflow branch)
- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/2006120804 Minefield/3.0a1 (post-reflow branch)

For Testcase 3, there is difference between:
- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/2006120606 Minefield/3.0a (pre-reflow branch)
- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/2006120804 Minefield/3.0a1 (post-reflow branch)
Namely the red border is always flush with the cell in the post-reflow branch, where as in the pre-reflow branch it sometimes only surrounded the < character

Comment 20

[Mats Palmgren (inactive)]

I get the same results as comment 19 in pre/post-reflow branch builds on Linux.

-> FIXED (by the reflow branch landing)