A tab character in a table cell can trigger: WARNING: Tabs encountered in a situation where we don't support tabbing: file /Users/jruderman/trunk/mozilla/layout/generic/nsTextFrameThebes.cpp, line 2293 Also, the border of the table overlaps the table cell, so the table seems to be confused about how long the text is. In bug 375058, Bernd said he thought this wasn't a table bug.

It's hard to determine the preferred or minimum width of text containing a preformatted tab, because the width of the tab depends on where the tab occurs in the line and thus on where line breaks have been placed. This testcase might be fixable but there are more general testcases that aren't. Any thoughts David?

I think, just like everything else, we should assume that we take all optional breaks for GetMinWidth, and don't take any optional breaks for GetPrefWidth. I'm having trouble thinking of what that wouldn't be sufficient for.

I guess you're right, if we use the current width in the InlineData as the x position to figure out where the next tab stop is, we should be OK. Inserting a break before a tab can never make the content wider, and removing a break before a tab can never make the content narrower.

This used to work in Firefox 2, so marking as regression.

here's a somewhat more general test case, with tabs at various points within a line: http://www.cs.cmu.edu/~dkindred/tmp/ff3-width-bug.html

Adding dependency on bug 230555 since the patch there treads on AddInline(Min/Pref)WidthForFlow which I need to change here.

Includes a reftest partially based on dkindred's testcase.

Comment on attachment 333892 [details] [diff] [review] fix > PRBool collapseWhitespace = !textStyle->WhiteSpaceIsSignificant(); > PRBool preformatNewlines = textStyle->NewlineIsSignificant(); >+ PRBool preformatTabs = textStyle->WhiteSpaceIsSignificant(); The extra boolean which is just equivalent to !collapseWhitespace seems redundant to me, but OK if you think it's worth it for clarity.

Pushed c4b0381a259b. I think the extra boolean helps clarity significantly.

Comment on attachment 333892 [details] [diff] [review] fix Pretty bad regression in 1.9, no regressions noted on trunk so far, so we might want to take on 1.9.0.x.

Comment on attachment 333892 [details] [diff] [review] fix Looks ugly, but I think we have to minus for the branch. Appeal to mconnor directly if you disagree.