Last Comment Bug 654928 - "ASSERTION: Didn't SaveReflowAndBoundingMetricsFor frame!"
: "ASSERTION: Didn't SaveReflowAndBoundingMetricsFor frame!"
Status: RESOLVED FIXED
: assertion, testcase
Product: Core
Classification: Components
Component: MathML (show other bugs)
: Trunk
: x86_64 All
: -- normal (vote)
: mozilla6
Assigned To: Karl Tomlinson (ni?:karlt)
:
Mentors:
Depends on:
Blocks: stirdom randomstyles
  Show dependency treegraph
 
Reported: 2011-05-04 23:32 PDT by Jesse Ruderman
Modified: 2011-05-12 21:58 PDT (History)
2 users (show)
karlt: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase (231.12 KB, text/html)
2011-05-04 23:32 PDT, Jesse Ruderman
no flags Details
stack trace (2.54 KB, text/plain)
2011-05-04 23:34 PDT, Jesse Ruderman
no flags Details
don't assume that the embellished operator is the first child (3.04 KB, patch)
2011-05-09 21:23 PDT, Karl Tomlinson (ni?:karlt)
fred.wang: review+
Details | Diff | Review

Description Jesse Ruderman 2011-05-04 23:32:18 PDT
Created attachment 530242 [details]
testcase

###!!! ASSERTION: Didn't SaveReflowAndBoundingMetricsFor frame!: 'metrics', file layout/mathml/nsMathMLContainerFrame.cpp, line 196
Comment 1 Jesse Ruderman 2011-05-04 23:34:44 PDT
Created attachment 530243 [details]
stack trace
Comment 2 Karl Tomlinson (ni?:karlt) 2011-05-05 17:01:51 PDT
> (gdb) call nsFrame::DumpFrameTree(0x7fff87dd59b0) 

[...]

>           Frame(maction)(0)@0x7fff87dd5118 {0,0,0,0} [state=0000000000000403] [content=0x7fff87d78680] [sc=0x7fff87d764c8]<
>             Block(maction)(0)@0x7fff87dd59b0 next=0x7fff87dd5280 [content=0x7fff87d78680] {0,0,0,0} [state=0000000000d00402] sc=0x7fff87ab9b90(i=1,b=0) pst=:-moz-mathml-anonymous-block<
>               line 0x7fff87dd5a68: count=1 state=inline,dirty,prevmarginclean,not impacted,not wrapped,before:nobr,after:nobr[0x1] {0,0,0,0} <
>                 Text(0)@0x7fff87dd5210 [run=0x7fff9493b160][0,1,T]  {0,0,0,0} [state=0000000040000402] [content=0x7fff87d78700] sc=0x7fff87dd5e48 pst=:-moz-non-element<
>                   "A"
>                 >
>               >
>             >
>             Frame(mo)(1)@0x7fff87dd5280 {0,0,0,0} [state=0000000000000403] [content=0x7fff87d78780] [sc=0x7fff87dd5910]<
>               Block(mo)(1)@0x7fff87dd57b8 [content=0x7fff87d78780] {0,0,0,0} [state=0000000000d00401] sc=0x7fff87dd5ee8(i=1,b=0) pst=:-moz-mathml-anonymous-block<
>                 line 0x7fff87d6e440: count=1 state=inline,clean,prevmarginclean,not impacted,not wrapped,before:nobr,after:nobr[0x100] {0,0,720,1140} <
>                   Text(0)@0x7fff87dd5480 [run=0x7fff9493b200][0,1,T]  {0,0,720,1140} [state=00000000d0600000] [content=0x7fff87d78800] sc=0x7fff87dd5870 pst=:-moz-non-element<
>                     "B"
>                   >
>                 >
>               >
>             >
>           >

"Frame(mo)" is the selected frame for the maction, but GetPreferredStretchSize
is looking at the first child of the maction, "Block(maction)".

Looks like GetPreferredStretchSize should to handle the
NS_MATHML_EMBELLISH_OPERATOR but
!(NS_MATHML_STRETCH_ALL_CHILDREN_HORIZONTALLY ||
NS_MATHML_STRETCH_ALL_CHILDREN_VERTICALLY)
case more generally than assuming the baseFrame is the first frame.
Comment 3 Karl Tomlinson (ni?:karlt) 2011-05-09 21:23:57 PDT
Created attachment 531240 [details] [diff] [review]
don't assume that the embellished operator is the first child
Comment 4 Frédéric Wang (:fredw) 2011-05-10 08:07:38 PDT
Comment on attachment 531240 [details] [diff] [review]
don't assume that the embellished operator is the first child

Review of attachment 531240 [details] [diff] [review]:
-----------------------------------------------------------------

That looks good.

Apart from maction, there is another case where the embellished op is not the first child: an mrow-like element whose children are one embellished op together with space-like elements. I think the patch fixes the issue for this case too.

fred@debian:~/mozilla/src/layout/mathml$ grep "mPresentationData.baseFrame =" *.cpp
nsMathMLContainerFrame.cpp:      mPresentationData.baseFrame = baseFrame;
nsMathMLContainerFrame.cpp:    mPresentationData.baseFrame = nsnull;
nsMathMLFrame.cpp:  mPresentationData.baseFrame = nsnull;
nsMathMLmactionFrame.cpp:  mPresentationData.baseFrame = mSelectedFrame;
nsMathMLmmultiscriptsFrame.cpp:  mPresentationData.baseFrame = mFrames.FirstChild();
nsMathMLmoverFrame.cpp:  mPresentationData.baseFrame = baseFrame;
nsMathMLmsubFrame.cpp:  mPresentationData.baseFrame = mFrames.FirstChild();
nsMathMLmsubsupFrame.cpp:  mPresentationData.baseFrame = mFrames.FirstChild();
nsMathMLmsupFrame.cpp:  mPresentationData.baseFrame = mFrames.FirstChild();
nsMathMLmunderFrame.cpp:  mPresentationData.baseFrame = baseFrame;
nsMathMLmunderoverFrame.cpp:  mPresentationData.baseFrame = baseFrame;
nsMathMLsemanticsFrame.cpp:  mPresentationData.baseFrame = mFrames.FirstChild();

Note You need to log in before you can comment on or make changes to this bug.