Don't know if this helps, but in nsMathMLmtableFrame.h there is

class nsMathMLFrame : public nsTFrame,
public nsMathMLFrame

with overrides on Init(), Reflow() and IsFType().
nsMathMLFrame::Reflow() calls nsTFrame::Reflow(), twice.

I can see how a Reflow() problem could cause the height issues in your
results, but I don't see how it would change the cell layout.

Henri Sivonen wrote:
In article <hsivonen-0403F8.14464604072006 (AT) news (DOT) mozilla.giganews.com>,
Henri Sivonen <hsivonen (AT) iki (DOT) fiwrote:

>Do other MathML element implementations besides mtable/mtr reuse the
>HTML table/tr layout code? That is, should I avoid flushing in other
>MathML elements besides mtr?

I tried making the math element itself monolithic the way the HTML side
handles HTML tr. It helped a bit, but the layout still breaks if I don't
wave the pointing device vigorously.

I constructed an XHTML table test case that has the same table structure
as the MathML test case. It is laid out properly regardless of how I
wave the pointing device. (I made XHTML tr monolithic as well.)

This makes me wonder: Does MathML reuse the HTML table layout code by
calling into the same code or has the code been forked? Is the work on
the reflow branch expected to make MathML layout stable regardless of
the flushing increments? That is, should I expect this to get sorted out
on the layout side or should I make an effort to work around the issue
in the content sink?

Screenshots:

dev-tech-mathml mailing list
dev-tech-mathml (AT) lists (DOT) mozilla.org