190593 - [BC] border-collapse problems at cellmap holes

Status: RESOLVED FIXED

(Core :: Layout: Tables, defect, P3)

Description

[Bernd]

see attached testcase there should be a horizontal line below the third cell in
the first row.

Comment 1

[Bernd]

Attachment: testcase

Comment 2

[Antony Mawer]

If you drag a window over the border-collapse:collapse'd table, you'll notice
that as you move it over and then away from the table, then the border lines
seem to display all kinds of weird repaintings (of varying length).

I had similar problems with borders being in the wrong place/not in the correct
place that I reported in bug 157047.

Comment 3

[Rob Adams]

just rediscovered this bug.  I had put together another testcase before finding
this bug.   I'll attach it just for laughs I guess.

Comment 4

[Rob Adams]

Attachment: testcase

Comment 5

[ameoba]

Attachment: testcase

The bug's still around.  I just spent an hour or two trying to narrow it down &
decided to add my test case.

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I cannot reproduce this on 2006012105-trunk/WinXP.

-> WFM (or dup of bug 147135?)

Comment 7

[Bernd]

The testcase that I wrote is still wrong, Masayuki before you mark a bug as WFM please make sure that you understand what the bug is about. This bug describes a problem that the  structure of the borders should be identical for border collapse and separate but they are not, see the additional vertical line in row 2. This makes also doubt that your WFM mark in the other bug is correct.

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Sorry.

But your comment 0 didn't say so. I think that your comment 0's bug is gone by another bug fix. However, there is still existing *another* problem, right?
And I don't think that this summary is good for actual problem.

Comment 9

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: testcase

If the table has border attribute, the non-existing cells have border. But if the table doesn't have border attribute, it's rendered correct.

Comment 10

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

I think that this is *not* a bug.

The border of non-existing cells are not so. These borders are TR's border and COL's border. These borders are specified by table[rules="all"]. When I commented out as following, attachment 209271 [details]'s both tables are same result.

http://lxr.mozilla.org/mozilla/source/layout/style/nsHTMLStyleSheet.cpp#254
> 254 static void ColPostResolveCallback(nsStyleStruct* aStyleStruct, ... 
> 255 {
      #if 0
> 256   ::ProcessTableRulesAttribute(aStyleStruct, aRuleData, ...
> 257                                NS_STYLE_TABLE_RULES_COLS, ...
> 258   ::ProcessTableRulesAttribute(aStyleStruct, aRuleData, ...
> 259                                NS_STYLE_TABLE_RULES_COLS, ... 
      #endif
> 260 }

Comment 11

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: testcase2

See this testcase. the right border of second cell of second row is gray or red. So, this border is column border. And the right border of third cell of second row is pink. So, this border is row border. If these borders are cell's border, they should be blue.

Comment 12

[Bernd]

Please either a) fix the bug and then do whatever you want with the description and feel free to invalidate my testcases, I am more than happy to review it or b) don't mess around with it. The description is a technical correct description of the issue. The description is intentional technical to make the bug usefull for people who are are able to fullfill choice a). See http://www.mozilla.org/newlayout/doc/table-cellmap.html what is a cellmap hole.

Comment 13

[Bernd]

fixed by bug 378935 the testcase there also cover this bug