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?
Created attachment 4721 [details]
testcase: conflict between text-indent and margin inside table
This is using Mozilla M13.
Under Windows, I get massive corruption of the browser window (<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,
Assigning all open "email@example.com" bugs to "firstname.lastname@example.org" to weed
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
I'll take this one and investigate further.
Created attachment 6311 [details]
re-applied testcase with correct MIME
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.
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.
Created attachment 11473 [details]
Created attachment 11474 [details]
Even simpler test case!
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.
Created attachment 11475 [details]
The REAL testcase
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
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.
Created attachment 11481 [details]
Example of the enormous difficulty of choosing correct desired width
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
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?
Created attachment 11502 [details]
margin-left and text-indent in 600 pixel table
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
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
Created attachment 11511 [details] [diff] [review]
Patch to nsBlockReflowContext::DoReflowBlock, nsBlockReflowContext::PlaceBlock
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.
Created attachment 11512 [details]
Screenshot of working table at www.thock.com/Dylan
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
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
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
I'm just looking for other things to work on in Mozilla, and I was pointed to
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.
Created attachment 11896 [details] [diff] [review]
V2 of patch to fix maxElementSize of elements with percentage margins and percentage-width content
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
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
roc, can you add an appropriate regression test to
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.