120487 - Different code path activated when MathML is enabled

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[rbs]

There is the following function the frame construction code which I don't grasp 
the rationale entirely. When MathML is enabled it falls back to PR_FALSE on 
exit. But when MathML is disabled, it falls back to PR_TRUE on exit. I am 
wondering what is the function supposed to do?

nsCSSFrameConstructor::MustGeneratePseudoParent(nsIPresContext*  aPresContext,
                                                nsIFrame*        aParentFrame,
                                                nsIAtom*         aTag,
                                                nsIContent*      aContent,
                                                nsIStyleContext* aStyleContext)
{
  if (!aStyleContext) return PR_FALSE;

  const nsStyleDisplay* display = (const nsStyleDisplay*)
    aStyleContext->GetStyleData(eStyleStruct_Display);

  if (NS_STYLE_DISPLAY_NONE == display->mDisplay) return PR_FALSE;
    
  // check tags first

  if ((nsLayoutAtoms::textTagName == aTag)) {
    return !IsOnlyWhiteSpace(aContent);
  }

  // exclude tags
  if ( (nsLayoutAtoms::commentTagName == aTag) ||
       (nsHTMLAtoms::form             == aTag) ) {
    return PR_FALSE;
  }

// XXX DJF - when should pseudo frames be constructed for MathML?
#ifdef MOZ_MATHML
  if ( (nsMathMLAtoms::math == aTag) ) {
    return PR_TRUE;
  }
  else {
    return PR_FALSE;
  }
#endif

  return PR_TRUE;
}

MustGeneratePseudoParent(

Comment 1

[karnaze (gone)]

The function is called during frame construction to decide if content which is 
not table related (i.e. table, row-group, row, col-group, col, cell) and which 
is misplaced inside table related content (e.g. a paragraph directly inside a 
row) needs to have an anonymous parent (e.g. a cell) constructed so that the 
content itself can have a frame constructed. If the function returns true then 
frames get constructed, otherwise they do not. So, back to you, rbs. 

Comment 2

[rbs]

Attachment: patch to cleanup

Since MathML is meant to be used in XHTML/XML, sloppy markups are frowned upon,
and users are expected to keep their markup neat and tidy. So I am just
removing that weird #ifdef.

Seeking r=karnaze, sr=waterson.

Comment 3

[rbs]

As part of my ongoing effort to drive the MathML code in default builds (if 
possible), I have iterated on the code that handles <mtable> and its related 
tags. To this end, I added another hook in the frame construction code to 
overload CreateTableCellFrame() from the mathml table creator. This has allowed 
me to support rowspan="." and columnspan="." which are called differently in 
HTML (rowspan & colspan) -- and which wouldn't work anyway since the table code 
fetches them from nodes that are supposed to be from the HTML content model. To 
get them to work in MathML, I overloaded the two getter methods in in 
nsMathMLmtableFrame.cpp so as to fetch the values from MathML nodes. I will 
attach the part of the changes that are in the frame construction code. As 
usual, in #ifdef MOZ_MATHML and economical (unless necessary otherwise) with my 
changes.

[karnaze -- see how your code is being used in other creative ways here...
screenshot - top half of improved <mtable> demo:
http://bugzilla.mozilla.org/attachment.cgi?id=66088&action=view
screenshot - bottom half of improved <mtable> demo:
http://bugzilla.mozilla.org/attachment.cgi?id=66089&action=view]

Comment 4

[rbs]

Attachment: upcoming iteration for m0.9.9

Comment 5

[karnaze (gone)]

Comment on attachment 66219 [details] [diff] [review]
upcoming iteration for m0.9.9

r=karnaze

Comment 6

[Chris Waterson]

Comment on attachment 66219 [details] [diff] [review]
upcoming iteration for m0.9.9

sr=waterson

Comment 7

[rbs]

Changes checked in.