User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6
"tooltip" actiontype of "maction" element of MathML does not work
Steps to Reproduce:
1. visit https://eyeasme.com/Joe/MathML/MathML_tooltip_bug.html
2. hover the cursor over the formula
3. no tooltip appears
no tooltip appears when the cursor is hovered over the formula
a tooltip should appear when the cursor is hovered over the formula
This page works OK with Opera but fails with Firefox.
NOTE: there is NO "title" attribute with MathML elements, so the
Firefox default way of displaying tooltips (using the "title" attribute)
does not apply.
The REC describes actiontype=tooltip like this:
"<maction actiontype="tooltip"> (expression) (message) </maction>
The renderer displays the first child. When the pointer pauses over the expression for a long enough delay time, the renderer displays a rendering of the message in a pop-up "tooltip" box near the expression. Many systems may limit the popup to be text, so the second child should be an mtext element in most circumstances. For non-mtext messages, renderers may provide a natural language translation of the markup if full MathML rendering is not practical, but this is not required."
Created attachment 600000 [details]
Created attachment 600001 [details]
testcase (MathJax rendering)
MathJax distinguishes text message (for which it uses HTML title) and MathML messages (for which it uses a div that it shows/hides with CSS). It looks like we can implement something similar by applying CSS rules to the second child of maction.
If we only want to consider text message (which is minimum required by the MathML3 spec), the relevant parts of the code to change seem to be:
The changes should be made in separate patches, since they are likely to be reviewed by different persons.
(and of course layout/mathml/nsMathMLmactionFrame.* too)
To come back to comment 4, here is how tooltip is implemented in http://www.w3.org/TR/mathml-for-css/ (and so in Opera):
maction > * + *
maction[actiontype="tooltip"]:focus > * + *,
maction[actiontype="tooltip"]:hover > * + *
The first rule hides the second child of the maction element. The other rule displays the second child as a tooltip when one comes on the maction element.
Putting something like this in layout/mathml/mathml.css and also handling when the second child is displayed in nsMathMLmactionFrame may allow to implement the tooltip actiontype, even for generic formula (as Opera and MathJax do).
That won't share the code for other text tooltip mentioned in comment 5 and maybe not give a consistent behavior, but at least the changes will be restricted to the MathML module, so more easily acceptable. One issue with this method is that the tooltip is placed at the top right corner of the page, not near the maction element. I don't know if we can change that.
After discussions with Andrii, the option in comment 5 seems the most appropriate. In the case where XUL is used for the UI (like in Firefox) the implementation relies on
It seems that this element can contain arbitrary children, so we could use MathML tooltip in that case.
Created attachment 631107 [details] [diff] [review]
patch XUL-enabled v1
Created attachment 631108 [details] [diff] [review]
patch XUL-disabled v1
These patches implement only <mtext> tooltip. There were some issues with MathML child tooltip, I won't be working with it in the nearest future.
Comment on attachment 631108 [details] [diff] [review]
patch XUL-disabled v1
I don't really know if XUL-disable part is needed, plus all these brackets look pretty weird. I can move this part into a new function, or remove at all.
Maybe we can also add a comment in
to indicate in which places of the code the tooltip actiontype is actually handled.
I don't think Andrii will continue to work on this bug. However, if I remember correctly his patches are complete and are just waiting to be reviewed. Probably they are now bit-rotten but I can update them and finish the work if necessary.
Gavin: Can you please give some feedback on this?
Comment on attachment 631107 [details] [diff] [review]
patch XUL-enabled v1
I'm sorry that I haven't been responsive here.
This model where the order of the children within the <maction> element matters is rather odd. It also seems very unusual to bake that kind of logic into the front-end code.
It would be more typical for this front-end code to look something like:
if (tipElement instanceof MathMLmactionElement &&
tipElement.actionType == "tooltip")
MathMLTitleText = tipElement.tooltipText;
But obviously that would require some Gecko changes, and I guess the MathML spec doesn't specify this kind of API?
Thank you Gavin.
I won't argue about the design of maction. This element has been there since the first MathML recommendation in 1998 and @actiontype=tooltip is currently implemented in Opera & MathJax and probably in Webkit soon. We can probably ask the Math WG to integrate the "title" attribute in the MathML syntax but they will certainly keep the tooltip actiontype for backward compatibility as well as for consistency with the other action types. Using children content instead of attribute value allows arbitrary mathematical formula as a tooltip, although not strictly required by the MathML spec. This is implemented in MathJax (attachment 600001 [details]) and Andrii was able to implement this most general syntax by copying the <math> inside <tooltip>. However, there were some issues with his approach and I recommended him to submit the simplest version with text-only tooltip so that the patch would have more chance to get accepted.
The MathML spec defined a DOM but we didn't want to implement it (see bug 377499 comment 48 and bug 143842 comment 17). As a consequence, the MathML WG removed it from the spec. It seems a bit overkill to add this API to Gecko and write more C++ code if that's only to simplify a few lines in the front-end code. Anyway, I'm afraid I won't be able to contribute to the MathML project for a while and the best I can do for this bug is to unbitrot these patches. So please tell me whether you think this small patch (attachment 631107 [details] [diff] [review]) is likely to be accepted or not and I'll see what I can do.