421324 - Firefox 3b4 doesn't render columns generated by Ext JS correctly

Status: RESOLVED DUPLICATE of bug 409736

(Core :: Layout, defect)

Description

[Frédéric Buclin]

Attachment: screenshot of the bad rendering

[Not sure about the component. Maybe a Layout:* one would be more suitable. I will let triagers redirect it if necessary]

Testopia is using Ext JS (http://extjs.com) to generate its output. The output is fine in Firefox 2.0.0.12, but columns are badly rendered with Firefox 3b4 (see the screenshot). Not sure if that's a bug in Firefox 3 or in Ext JS, but it worths some investigation before the final release of Fx3.

I added in the URL field a discussion about this problem, in case someone is interested.

Comment 1

[Bob Clary [:bc] (inactive)]

http://extjs.com/deploy/dev/examples/grid/xml-grid.html appears to be an example of this.

Moving to Core:General at least temporarily until it is better diagnosed. If someone can help get a regression range that would be nice.

Comment 2

[Bob Clary [:bc] (inactive)]

regression range 2007-12-04-04 2007-12-05-04

Check in city: <http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-12-04+04%3A00%3A00&maxdate=2007-12-05+04%3A00%3A00&cvsroot=%2Fcvsroot>

Comment 3

[Sylvain Pasche]

I'm getting the same behavior with WebKit. Looks like to be bug 402567.

This can be considered a bug in ExtJS. They could add a max-width constraint on the cells to get the same effect as Firefox 2 or Opera. Anyone willing to report the bug?

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I think this is probably wontfix or tech evang.

Comment 5

[Frédéric Buclin]

(In reply to comment #4)
> I think this is probably wontfix or tech evang.

Why WONTFIX? What changed in Fx3 which now breaks the alignment of columns?

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

dbaron or dholbert would best answer that.

Comment 7

[Frédéric Buclin]

(In reply to comment #6)
> dbaron or dholbert would best answer that.

David?

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

On what simplified testcase?

Comment 9

[Frédéric Buclin]

(In reply to comment #8)
> On what simplified testcase?
> 

I don't know. You mentioned wontfix, so I guessed you had a good reason to say so. :)

Comment 10

[Daniel Holbert [:dholbert]]

(In reply to comment #5)
> (In reply to comment #4)
> > I think this is probably wontfix or tech evang.
> 
> Why WONTFIX? What changed in Fx3 which now breaks the alignment of columns?

Seeing as the breakage traces back to the landing of bug 402567, I'm guessing it's that min-width now gets passed through "overflow: XXX" frames (where XXX is one of scroll/auto/hidden)

Among other reasons, this change was because (a) it makes us behave more sensibly, and (b) it makes us match IE7 and WebKit, for better Web Compatibility.

Here are a few some comments regarding this decision, for reference:
 - bug 402567 comment 22
 - bug 402567 comment 23
 - bug 309110 comment 34
 - bug 309110 comment 36

Comment 11

[Sylvain Pasche]

Attachment: reduced testcase

Comment 12

[Daniel Holbert [:dholbert]]

Attachment: clearer reduced testcase

(made the table contents longer to illustrate what's going on here)

These testcases confirm that Comment 10 was right about what's changed here.

Basically, in FF2, the overflow:hidden div had a min-width of 0px, but now it has a min-width equal to its contents' min-width.

And since tables expand to accommodate their contents' min-width, the table expands to show the full long string of text.

(If the wrapper was a specified-width div instead of a specified-width table, then FF2 and FF3 both cut off the string as desired, because divs don't stretch the way that tables do.)

Comment 13

[Brian Moeskau]

Hi, I'm an Ext core dev.  I'm not sure I understand why it's sensible to push TDs out of alignment with their columns based on content width?  I can understand maybe causing the entire column to honor the widest min-width of its cells, but I don't understand how the current rendering makes sense.

So what exactly is our fix?  I tried playing around with min-width but got nothing that worked.  I'm able to "fix" it using max-width, but that would require recalculation of every cell on every column resize which would be undesirable.  Is there a setting that will allow the browser to auto-calculate the width/overflow correctly?

"If the wrapper was a specified-width div instead of a specified-width table..."  Which wrapper are you referring to?  Each cell is a TD (x-grid3-col x-grid3-cell) wrapping an inner DIV (x-grid3-cell-inner).

Comment 14

[Brian Moeskau]

"I'm not sure I understand why it's sensible to push TDs out of alignment with their columns based on content width?"

Sorry, scratch that last comment.  I just remembered that each row is a separate table, so of course the columns won't match up in this case.  But any help with the fix would still be appreciated.

Comment 15

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I'm not sure exactly what it is that you're doing, but it might be fixed by putting a div with width:0 inside the div with overflow:hidden.

It does bother me a bit that authors don't really have any way to choose between these two behaviors; I think the new one is better by default, but I can certainly see why authors want the old one in some cases.  (Though, perhaps, in that case, tables aren't really the right container to be using.)

Comment 16

[Sylvain Pasche]

(In reply to comment #13)
> I'm able to "fix" it using max-width, but that would
> require recalculation of every cell on every column resize which would be
> undesirable.

Aren't you already changing the style="width: ..." on each <td> element during a resize? You could set a max-width to the same value as the width at the same time, which shouldn't bring significant overhead.

Comment 17

[Brian Moeskau]

We updated our grid CSS to include "table-layout:fixed;" and that seems to have resolved the issue for us.

Comment 18

[Frédéric Buclin]

(In reply to comment #17)
> We updated our grid CSS to include "table-layout:fixed;" and that seems to have
> resolved the issue for us.

Brian, is this fix available in ExtJS 2.1.0 released yesterday?

Comment 19

[Brian Moeskau]

Yes, it should be fixed.  If there are still any issues, please let me know.