Closed Bug 370353 Opened 18 years ago Closed 18 years ago

Dynamically setting 'visibility: collapse' to a <col> no longer works

Categories

(Core :: Layout: Tables, defect)

x86
All
defect
Not set
normal

Tracking

()

VERIFIED FIXED

People

(Reporter: bugzilla, Assigned: dholbert)

References

()

Details

(Keywords: regression, testcase)

Attachments

(6 files, 1 obsolete file)

This bug comes from bug 76497 comment #c19. The collapse examples found at http://www.mozilla.org/newlayout/samples/test4.html work as expected. Test #5 (<col> visibility with border-collapse: separate) and test #7 (<colgroup> visibility with border-collapse: separate) taken from the provided URL ( attachment 147933 [details] ) were working before (say, ~=6 weeks; after reflow branch; at the time when table caption became as wide as document, not as wide as table). Now, they do not. Same thing with the demo page http://www.gtalbot.org/DHTMLSection/TableRowColumnCollapse.html Bug happens in Seamonkey 1.5a rv:1.9a3pre build 2007021310 under XP Pro SP2 here. Reduced, minimized testcase coming up.
Attached file Reduced testcase
Load the testcase. Press the button. Expected results: 2nd &lt;col&gt; should collapse Actual results in Seamonkey 1.5a rv:1.9a3pre build 2007021310 under XP Pro SP2: 2nd &lt;col&gt; does not collapse Note: Firefox 2.0.0.1 rv:1.8.1.1 build 20061204 renders the expected results.
Keywords: testcase
Summary: Dynamically setting visibility collapse to a &lt;col&gt; in border-collapse: separate no longer works → Dynamically setting visibility collapse to a <col> in border-collapse: separate no longer works
If someone could please check this in, at the latest when this bug gets fixed, that would be great.
> Firefox 2.0.0.1 rv:1.8.1.1 build 20061204 renders the expected results. The previously working marking mechanism is probably not compatible with the code after the reflow branch and gets not executed. The code in question is at http://lxr.mozilla.org/seamonkey/source/layout/tables/nsTableColFrame.cpp#107. One can verify that the collapsing itself works by selecting first a column and then a row to collapse at http://www.gtalbot.org/DHTMLSection/TableRowColumnCollapse.html
Comment on attachment 270099 [details] reftest version of testcase Sounds like we should go ahead and check in the test for this into reftest. Bernd, are you the right person to review that?
Attachment #270099 - Flags: review?(bernd_mozilla)
Attachment #270099 - Flags: review?(bernd_mozilla) → review+
Flags: blocking1.9? → blocking1.9+
Assignee: nobody → dholbert
The "border-collapse: separate" doesn't seem to be necessary to trigger the bug. Here's a much more reduced testcase.
Status: NEW → ASSIGNED
OS: Windows XP → All
The problem is that the table.mBits.mHaveReflowedColGroups flag is set to 1 on the table's first load, and then it's never cleared after that. As a result, nsTableFrame::ReflowColGroups returns early, which prevents us from hitting the code mentioned in comment 4. So, it looks like we need to do one of the following: a) clear table.mBits.mHaveReflowedColGroups at some point b) call nsTableColFrame::Reflow at some other point. (i.e. some place triggered by the style change, outside of the table-reflow process)
OS: All → Windows XP
Summary: Dynamically setting visibility collapse to a <col> in border-collapse: separate no longer works → Dynamically setting 'visibility: collapse' to a <col> no longer works
D'oh, somehow I changed OS back to WinXP... I think maybe I posted my last comment on an old version of the page. Setting to "All" again. Sorry for the bugspam.
OS: Windows XP → All
Attached patch patch with whitespace issues (obsolete) — Splinter Review
probably it would even better to do it conditional if NeedToCollapse() is true
forget the last proposal its wrong
RE attachment 275639 [details] [diff] [review] -- talked to dbaron, and he said this approach is probably fine. While it means we'll reflow the col groups more than we need to, it's pretty cheap to reflow them. One possible addition / optimization would be to check if a col group is dirty before we reflow it, as we do with (row groups) in nsTableFrame::ReflowChildren Gonna try that out and see how that works.
Clear "mHaveReflowedColGroups" on each table reflow, but also check for col-group dirtiness, so that we only reflow a col-group if its subtree is dirty.
Attachment #275677 - Attachment description: patch, checking colgroups' dirtiness → patch v2: checking colgroups' dirtiness
Attachment #275679 - Flags: superreview?(dbaron)
Attachment #275679 - Flags: review?(bernd_mozilla)
Here's a patch version of ispiked's zipped testcase (which was attachment 270099 [details])
Attachment #275679 - Flags: review?(bernd_mozilla) → review+
Comment on attachment 275679 [details] [diff] [review] patch v2 (no-whitespace-changes version) sr+a1.9=dbaron. Make sure that if somebody checks this in for you, the check in the version with the whitespace changes :-)
Attachment #275679 - Flags: superreview?(dbaron)
Attachment #275679 - Flags: superreview+
Attachment #275679 - Flags: approval1.9+
Attachment #275639 - Attachment is obsolete: true
Checking in layout/tables/nsTableFrame.cpp; /cvsroot/mozilla/layout/tables/nsTableFrame.cpp,v <-- nsTableFrame.cpp new revision: 3.700; previous revision: 3.699 done
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Checking in layout/tables/nsTableFrame.cpp; /cvsroot/mozilla/layout/tables/nsTableFrame.cpp,v <-- nsTableFrame.cpp new revision: 3.701; previous revision: 3.700 done Landing the patch with the whitespace changes like I was supposed to. :)
Checked in the reftests too.
Flags: in-testsuite+
We really need to get dholbert his cvs account ;)
VERIFIED with Seamonkey 2.0a1pre rv:1.9a8pre build 2007082102 under XP Pro. Thank you all!
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: