See url and upcoming testcase. You should see some text in the page, but this doesn't show up anymore in current trunk builds. This regressed between 2006-01-25 and 2006-01-26, probably a regression from bug 317375. (be careful of looking at the url testcase on branch builds, it crashes with those builds)

The testcase creates an anonymous table with two captions, which is weird but I guess we have to handle it like all other weird stuff :-). The fix is easy, just make tables paint/handle events on all caption frames instead of just the first one.

Actually, bz suggests that the second table caption should be treated as display:none, in which case this bug is INVALID.

I seem to remember us going the other way in the past. Do we reflow all caption frames? How do we handle differing values of 'caption-side'?

See bug 309322 for where the current setup got implemented. > Do we reflow all caption frames? No. We only reflow the first one in the list. This is independent of having different caption-sides. I guess what we have is not quite display:none, since we do have frames.... I suppose that we could change things to actually reflow and paint multiple captions, if we can figure out how to do it right. What to do with multiple captions per side?

As far as I can tell, we only reflow the mCaptionFrame. So this patch is "safe" in the sense that second and later captions won't get reflowed and won't draw any normal content ... we still need to descend into them to paint through placeholders inside them, as in this bug, if we think that content should be rendered. The spec should say whether it is or not.

>I seem to remember us going the other way in the past. We had previously a mechanism that destroyed the second caption once we realized that it is the second caption during frame construction. This was pretty difficult to maintain. It crashed every now and then. Then I proposed/implemented that we do not destroy the unwanted caption but keep it in the secondary child list. Only the first child gets reflowed and displayed. This is a difference between trunk and branch.

I believe that the true bug is that we should wrap both captions into two different outer table frames. Which then will paint its children. For me the patch is wrong.

The patch could still be useful because you could still have a table with two captions, even though this testcase wouldn't. It all depends on whether out-of-flow children of a second caption should be displayed or not.

I believe they should not be displayed. What I would like to have is the sibling suppression, the best would be if it would have display:none due to the style resolution. As far as I understand CSS this can't be achieved by a CSS rule. The best simulation of this behavior is to not show the caption and all its children having a virtual display:none on the second caption.

Can this bug be marked invalid?

I think so. It seems no-one is willing to argue that the second caption's out-of-flow children should be displayed.