It looks like the CSS1 parser has caused major problems. The entire client area seems to be filled with random bits of text and graphics. It could be an array that wasn't properly terminated, or just a general memory leak or pointer confusion, but the entire window slowly randomises itself :-)

changed component to Style System. Dylan, what build are you using?

This is using Mozilla M13. Under Windows, I get massive corruption of the browser window (<a href="http://www.thock.com/Dylan/M13_tasties.jpg">screenshot</a>). Under Linux (2.2.15pre4/October Gnome/IceWM v1.0.1/XF86_SVGA 3.3.5), I get a bunch of text that does not wrap propely (long horizontal scrollbar). This is using a prebuilt binary with fullcircle talkback. M13 on Linux and Windows both misrender <a href="http://www.thock.com/3ilinux/">http://www.thock.com/3ilinux/</a> the same, though :-)

Assigning all open "nobody@mozilla.org" bugs to "leger@netscape.com" to weed thru.

Reassign to component owner.

I'm not seeing the major corruption, however the right-margins are clearly wrong as the text goes on and on toward the right without wrapping, as Dylan mentioned. I'll take this one and investigate further.

This looks like a table layout problem. When both margin-left and text-indent are specified in percentages the table is way to wide. If either one is specified in em or px units, then it is fine. Assigning to karnaze since the style looks correct.

Buster, it looks like the cell's block is returning a very large desired and max element size upon an unconstrained reflow.

redistributing bugs across future milestones, sorry for the spam

This bug has been marked "future" because we have determined that it is not critical for netscape6.0. If you feel this is an error, or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.

Cool screenshot. Do I understand it correctly, that we won't be CSS1-compliant with this bug?

This bug means that valid HTML 4.0 and CSS1 will not work. There is no way that Netscape/Mozilla can go gold without *full* CSS1 HTML 4.0 compliance IMHO. It's the only way to stand out.

Full HTML4/CSS1 compliance can't mean "100% bug free". If it does, no-one will ever ship a fully copmliant browser.

Right, but that is no reason to avoid fixing bugs either. There is a long time before the final release. Bugs that break compliance should be ahead of everything else except crashers.

I agree, if it breaks compliance then it should be fixed. Before Netscape PR3 - thats not exactly tomorrow.

Buster, thanks for considering this bug. Jan, you seem to be the correct QA this bug needs to be fixed. Buster, I'm sorry about your workload, could you possibly give a hint about how someone would fix this? Milestone reset by /. Justification for loss of future: /., css1 relnote2: if we don't fully support css we need to say so. nsbeta3: css1

First observation: incremental reflow of "text-indent: n%" is broken. It's easy to fix. I have filed bug 45631 with a patch.

Sorry, ignore those testcases. I'm confused.

Some of my comments below may be wrong if you're flying without the incremental-text-indent patch. Table layout depends on incremental reflow; there's no point in attacking this bug until incremental reflow of text-indent is fixed. If you open attachment 11475 [details] in Viewer, you will see that the layout is wrong. The table is unnecessarily wide. In fact, the table will always be as wide as the window. In fact, the table edge should be to the right of the text, i.e. the table should be sized so that the text should occupy 60% of the width and the identation the other 40%. Note that NS 4.x bungles the layout in a different way: the indent is set to 40% of the window width, and then the table is laid out around that. Currently what happens in Gecko is that the line is initially reflowed with unconstrained width. We calculate the text-indent as 40% of some very large number, which results in another very large number :-). Then we set the desired size to that plus the width of the text. The desired size is never updated again... The table sets its size, then the cell is reflowed to fit (which updates the text-indent amount, but does not change the desired size). (I'm pretty sure that the insanity that results in combination with "margin" is a consequence of the unreasonable desired cell width. Even if it isn't, we should get text-indent in tables working before we tackle the real bug.) The problem here is simply that reflowing with unconstrained width does not tell us the desired width of the block. I tried detecting the special case of taking the text-indent percentage of NS_UNCONSTRAINEDSIZE and returning 0 for the indent, but of course that just gives you a different wrong estimate of the desired width (although one that's a lot more reasonable). Similar (although less spectacular) problems happen if you put a replaced-inline element into the cell, styled with a percentage width. The solution is not going to be easy, but this should work: while reflowing a block with unconstrained width, accumulate in the block's reflow state an "additional percentage width required" factor. Things whose width is a percentage of the unconstrained-width-block are assigned zero width but add their percentages into the accumulator. Then we can calculate the desired width of the unconstrained-width-block by solving the equation desired_width = measured_contents_width + desired_width*accumulated_percentages Heh heh heh.

Oh dear. More bad news about "text-indent" is that it is one of the few inheritable percentage styles, and we need to inherit the computed value instead of the percentage. Currently we inherit the percentage. This breaks in situations like this: <div style="text-indent: 10%; width: 100px;"><p>hellohello</p></div> The indent should be 10% of the width of the DIV's containing block, but Gecko is making it 10px (10% of the width of the DIV) regardless of the width of the DIV's containing block. Making that work right is also going to make fixing this bug harder.

I was overly optimistic last night. The previous example shows just how difficult it is to choose the desired cell width. At large widths, the table fits in two lines. At smaller widths (~250px), it wraps to three lines. At yet smaller widths (~180px), it fits in two lines again! And if you keep making it smaller, it goes back to three lines. So, the question is, how should this table be laid out if the table width is unconstrained? Ideally I think we should choose the smallest width that minimizes the height, but that means we need to globally optimize a function with multiple local minima. That's fundamentally hard. As a possible first step, when taking the precentage of an NS_UNCONSTRAINEDSIZE, always return some fixed very large value (independent of the %) so that if we add a lot of them up, we won't overflow, but we will always get a very large width. Then when we compute the desired size of a table cell, we can detect over-wide cells and invoke a more complex "desired size search" subroutine. This way we avoid penalizing the common case. The big question is, exactly what should this subroutine do? We can try reflowing the cell into different widths and see how it fits, but how can we detect that it's fitting well? A stopgap measure would be to force the table width to the width of its container if we see a strangely-wide child.

As an authoring practice, using percentage widths inside table cells whose width is otherwise unconstrained is probably unwise. Those measurements depend on the width of the cell, but the width of the cell depends on those measurements. No wonder no browsers get it right.

Follow the logic here. Nested tables should inherit their sizes fairly easily. The outer table has its percentage size translated into a hard pixel value. Then the next inner table has its size based on its percentage of the outer one. And so on. You could evaluate this recusesively. Once you have a size for a table, it's simply a matter of dividing the space among the cells. Then once you have a cell size and position within the table, you put the content into it. This is where indentation and margins come in, and are relative to the size of the cell. That's my reasoning behind it, but then I've never tried to program a layout engine (or browser for that matter) before :)

That's great if the page author specified the table width. That already works fine in Mozilla. The problem is when the table width is not specified at all so the browser has to find a good width.

This bug has to do with a conflict between margin-left and text indent when in percentages within tables. Even when the width of the table is set, I don't think it works properly in Mozilla. Otherwise, this bug would be marked FIXED and you guys would be using a different bug # for the problem with unconstrained tables. If there is a width:X% specified for a table, then it should be easy for it to get the amounts for margin-left:X% and text-indent:X% from the table's width, which is gotten from the page's width. If it isn't specified, maybe anything that is specified in percentages within these kinds of tables should be ignored. I don't think anybody would have something against doing this if the W3C forgot to mention that specifying things in percentages within tables that don't have specified widths or heights might not work correctly.

Maybe I'm just dense, but eventually Mozilla has to layout a table that has no specified width right? Why not use that size to determine the %'s?

"Otherwise, this bug would be marked FIXED and you guys would be using a different bug # for the problem with unconstrained tables." So is there a bug open for unconstrained tables, or are unconstrained tables symptoms of the indent/margin percentage conflict?

The deal with margins is this: the text indent is set to a bogusly large value, as I explained earlier. Therefore the P element's contents are bogusly wide. The P element is "shrink wrapping" its contents here, so its margins are calculated so that the left margin will be 1% of the final P width, i.e. the left margin is set to bogusly wide too. The sting is that when we look to see what the minimum cell width should be (the "maxElementSize"), we scan the contained P element to see what its "maxElementSize" is; we find that it's the width of the string plus the margins on the element! So we incorrectly decide that the element needs to be incredibly wide. I think this means we should change nsBlockReflowContext::PlaceBlock so that it recomputes the margin values based on the maxElementSize (i.e. the minimum width required for the block) instead of the actual width.

There are a number of different bugs falling over each other here: 1) percentage text-indent doesn't inherit in the right way (bug 45631) 2) percentage text-indent doesn't incrementally reflow correctly (bug 45631) 3) table cells containing percentage text-indent and percentage width inline-replaced elements don't size correctly 4) the minimum width of shrink-wrapped blocks with percentage margins isn't set correctly Bugs 2), 3) and 4) are all affecting this bug report. Bug 4) is probably causing the worst of the trouble. Thanks for pointing that out. Bugs 1) and 2) really need to be solved together; they're tricky, but solvable. Bug 3) is a nightmare and probably deserves its own Bugzilla bug. Bug 4) is definitely solvable and should probably stay here.

Bradley: the problem is that you can't just use the table width to compute the margin and text-indents, for two reasons. First, if the minimum width of the columns is wider than the specified table size, Mozilla will make the table wider to fit. I don't know if that's a good decision, but it seems to have been done deliberately. Also, if there's more than one column you have to figure out how to distribute the space and that's not easy. Jerry: Apart from the margin bug, the problem is all about how to choose the table width. If that's done correctly, everything else should work. But it seems terribly difficult to do "correctly", if indeed there is any correct way to do it.

The patch fixes the margin issues. The tables in this bug's testcases and on other sites seem to work OK. text-indent in tables still doesn't really work, but at least things don't get out of control.

I have another idea for getting a reasonable desired size for table cells containing percentage-width elements. First, set things up so that when we reflow a table cell with unconstrained width to find its desired width, we can specify as a parameter the actual (very large) width that percentage-width children will base themselves on (the "putative width"). Right now they (or at least some of them) take a percentage of the value of NS_UNCONSTRAINEDWIDTH, which is just dumb. Now, it seems to me that the desired width of a table cell in terms of this putative width should be a linear function, i.e. the desired width will normally consist of some fixed width "x" plus some fraction "f" of the putative width. I have a hard time thinking of content which could violate this rule (assuming the putative width is very large). If so, then we can do the following: first reflow the cell with unconstrained width and a very large putative width W. If the resulting desired width D is not unreasonably large, then we're done. Otherwise reflow the cell again with unconstrained width and putative width W/2, obtaining desired width E. Then, by the assumption, D = x + fW and E = x + fW/2 Solving the equations, we get f = 2(D - E)/W and x = 2E - D We'd check 0 < f < 1 and 0 < x and bail out (or do something else special) if not. Otherwise we can go ahead and compute the true desired width "T" by solving the equation T = x + fT i.e. set T = x/(1 - f) Should be fast, robust and give good results.

I'll start looking at this.

What do you plan to look at? My patch fixes the issues with percentage margins in the presence of percentage-width content making the minimum cell width unreasonably large. That patch should be enough to consider this bug "fixed". The desired cell size calculation is still broken in the presence of percentage-width content, but it turns out that all the ideas I posted here are flawed and will give bad results. I have other ideas but they're complex and slow and the problem is so hard, it's really not worth fixing.

So has your patch been committed? Should we open another bug to work on desired cell size computation? I'm just looking for other things to work on in Mozilla, and I was pointed to this bug. Should we add "Fix in hand" to the status whiteboard?

The patch hasn't been committed. I'm actually going to submit a new patch, which is slightly lower risk. If you can try it out, verify that it fixes the bug and doesn't cause any new problems, and report so here, that would be very helpful. Then I can seek review and approval and check it in myself. Filing a new bug about choosing correct desired cell widths in the presence of percentage-width content would be a fine thing to do, but please don't burn time on it. I don't think anyone really cares about it.

If anyone files that cell-width bug, please CC me on it. Thanks.

I think that patch is checkin-worthy. However, let's wait until nsbeta2 has branched before we seek approval. This is minor stuff. I'm stealing the bug from buster. I hope he doesn't mind :-).

OK, can I have review and module owner/mozilla.org approval please? It's time to get this in. The patch is http://bugzilla.mozilla.org/showattachment.cgi?attach_id=11896

CC'ing attinasi@netscape.com

a=waterson

Do we still need r=? Marc, assuming this falls into your module, could you review the patch please? Thanks...

It would be better if Chris W. could review this, he is much more familiar with this are than I am. Chris, can you review the patch (http://bugzilla.mozilla.org/showattachment.cgi?attach_id=11896)?

r=waterson, too! roc, can you add an appropriate regression test to mozilla/layout/html/tests/table/bugs, too?

Fix and testcase checked in.

I have double checked several times with recent builds and, to my great joy, this indeed works fine (and fixes problems with rendering other things I was doing with CSS and HTML). I'm glad that something originally marked as "future" was just a simple patch away from proper HTML/CSS conformance :)

Mass removing self from CC list.

Now I feel sumb because I have to add back. Sorry for the spam.