Created attachment 251941 [details] testcase 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.
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.
Created attachment 301635 [details] [diff] [review] patch Well, that's simple enough. I haven't tested this; I'll do so tomorrow.
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.
Checked in to trunk, 2008-02-08 11:56 -0800.
I checked in two reftests, one for fixed->auto and one for auto->fixed.