Try to call DumpRenderTree on the attached testcase. You'll get the "mtext" text but not the "mo" text.
I'm moving this to Tools/Tests as I think that's something that could be fixed in rendering/RenderTreeAsText.cpp or similar. Any suggestion for how to do that would be welcome.
Created attachment 218996 [details] testcase
RenderTreeAsText.cpp is only used when you do *not* call dumpAsText. The testRunner.dumpAsText feature is implemented with the DOM innerText function, so there is not necessarily a way to fix this without changing the behavior of the DOM. The innerText function, in turn, is based on the text iterator in TextIterator.cpp, which is the same code used for things like converting a selection to plain text on the clipboard when you select and copy something, or searching for text with the browser’s find command. So this is likely a bug in the MathML implementation and not a tools issue, assuming that we want text from inside an <mo> to be copyable and searchable, etc. The text iterator primarily iterates the DOM and not the render tree. It does not have any code to dig inside of the kind of render tree that RenderMathMLOperator::updateFromElement builds. We could add code for that, or we could simply add special case code to TextIterator::handleNonTextNode to handle RenderMathMLOperator specially.
Thank you Darin. Indeed, the patch for bug 124838 seems to break text selection of token elements. So I'll have to check what text iterator is doing and how it could handle MathML text better.
Changing the direction of the dependency since I'll probably fix the issue while doing the refactoring code of MathML token elements. Some test references are currently incorrect with the <mo> text not appearing in the expected output.
(In reply to comment #4) > Indeed, the patch for bug 124838 seems to break text selection of token elements. That is an even-more-fundamental issue with the same underlying cause: A render tree that is not linked to a DOM tree in the usual way. Text selection is done by other editing code and is not handled by the text iterator, so text iterator changes will not fix that. We may need to use a shadow DOM approach as elements like the slider do rather than just creating a set of renderers. Not really my area of expertise.
(In reply to comment #6) > (In reply to comment #4) > > Indeed, the patch for bug 124838 seems to break text selection of token elements. > > That is an even-more-fundamental issue with the same underlying cause: A render tree that is not linked to a DOM tree in the usual way. Text selection is done by other editing code and is not handled by the text iterator, so text iterator changes will not fix that. > > We may need to use a shadow DOM approach as elements like the slider do rather than just creating a set of renderers. Not really my area of expertise. Yes, I've been able to get something for the text output but not the selection. If that's too complicated, I'll first try to do the refactoring that is necessary for 99620 on the mo element only and come back to this later.
On Alex's MathMLLayout branch, DumpRenderTree on the testcase now generates the expected "mo" test. Actually, the MathML layout code no longer uses any anonymous nodes for RenderMathMLOperator / RenderMathMLToken, instead we just different measuring / painting functions when necessary.
Fixed after r202420