While investigating a bug, I discovered that RenderMathMLOperator is still creating non-anonymous renderers for wrapping children. AFAICT this shouldn't happen as David migrated all wrappers to be anonymous but it looks like those were forgotten.
They weren't forgotten. One problem is that I'd heard anonymous blocks shouldn't have layers, though I could never find out why.
The MathML wrappers change to mostly anonymous was in bug 88476.
(In reply to comment #1) > They weren't forgotten. One problem is that I'd heard anonymous blocks shouldn't have layers, though I could never find out why. That's my fault for saying that. My apologies. I will post a patch to make them fully anonymous, feel free to push back if this looks wrong.
Created attachment 177880 [details] Proposed change.
No apologies necessary. Can anonymous renderers have layers? What exactly is the problem? Is it ok for anonymous flexboxes, just not "anonymous blocks" introduced by RenderBlock? I am worried because this wrapper may have a layer. I will have to go back and look to see if there's another reason I didn't make these truly anonymous.
> Can anonymous renderers have layers? Nothing really prevents an anonymous renderer to have a layer as the decision to have / not have one is based on the style and in some rare cases on the parent (see bug 91405 for example). All of the properties generating a layer (e.g. opacity or transform) are not inherited so this case doesn't happen usually. > What exactly is the problem? This is the type of problem that arise if we relax the restriction: http://trac.webkit.org/changeset/111439. This is what prompted me to say that would should probably hold off making more anonymous renderers with layers. Reading back, this was an isolated bug so I over-reacted - though we have to be mindful of the probable badness. As we have proper coverage these days, we should probably try it to see if something actually breaks. > Is it ok for anonymous flexboxes, just not "anonymous blocks" introduced by RenderBlock? I am worried because this wrapper may have a layer. One wrapper will have a layer as we set overflow: hidden on it.
Looks great to me. The other place with "almost anonymous" renderers is RenderMathMLFenced.cpp. You could change: RenderMathMLOperator* newOperator = new (renderArena()) RenderMathMLOperator(node() /* "almost anonymous" */, uChar); to use document() instead of node(). You'd then need to change RenderMathMLFenced::styleDidChange to make sure it applied the special margins to its anonymous children. (The FIXME saying to just remove RenderMathMLFenced::styleDidChange is outdated.) Or if you wait until the MathML operator dictionary is implemented (which gives default margins for all standard operators), these special margins and RenderMathMLFenced::styleDidChange could just be removed.
What's the status on this bug? Looks like it was approved but never landed. I'm sure it's out-of-sync with the archive now, but do we still want to take this?
(In reply to comment #8) > What's the status on this bug? Looks like it was approved but never landed. > I'm sure it's out-of-sync with the archive now, but do we still want to take > this? @Brent: This will probably be obsolete after bug 155018, where we remove the need for anonymous renderers for MathML token elements.