Closed Bug 367375 Opened 16 years ago Closed 15 years ago
Dynamic changes to table-layout property have no visible effect
Steps to reproduce: 1. Click the first button in the testcase. 2. Click the second button in the testcase. Expected: layout changes after step 1 (only) Result: layout changes after step 2 (only)
I still see this bug on trunk.
The testcase above doesn't show the bug on current trunk due to a change in bug 368600 that made "table-layout: fixed" be ignored if the table's width is "auto". (This might get reverted; see bug 400776.) I'll attach a new testcase that does demonstrate this bug on trunk.
I see this on Linux as well, with FF 3.0b2. (using 'testcase 2') OS / Platform --> All.
OS: Mac OS X → All
Hardware: Macintosh → All
nsStyleTable::CalcDifference returns NS_STYLE_HINT_REFLOW for mLayoutStrategy differences. I think we either: (1) need to make nsTableFrame::MarkIntrinsicWidthsDirty check that the layout strategy is still the correct type (which may involve a little other work to initialize it correctly), or (2) return a framechange hint instead of reflow.
I prefer the framechange hint as we keep the layout strategy as a overloaded member variable that triggers very different functions to be loaded.
Well, that's simple enough. I haven't tested this; I'll do so tomorrow.
Assignee: nobody → dbaron
Status: NEW → ASSIGNED
Comment on attachment 301635 [details] [diff] [review] patch Trivial patch to change the style hint for nsStyleTable::mLayoutStrategy changes to NS_STYLE_HINT_FRAMECHANGE.
Comment on attachment 301635 [details] [diff] [review] patch Looks good.
Comment on attachment 301635 [details] [diff] [review] patch Trivial patch; very low risk.
Attachment #301635 - Flags: approval1.9?
Checked in to trunk, 2008-02-08 11:56 -0800.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
I checked in two reftests, one for fixed->auto and one for auto->fixed.
Flags: in-testsuite? → in-testsuite+
You need to log in before you can comment on or make changes to this bug.