See Firebug bug 1725 (http://code.google.com/p/fbug/issues/detail?id=1725) as to why this bug should be fixed.
reassigning somewhere more appropriate, hopefully.
> http://groups.google.fr/group/mozilla.dev.tech.mathml/browse_thread/thread/1e252307246e7e94 > getBoundingClientRect seems to provide correct values for all the > elements inside a math element, but not for the math element itself. I wonder whether the patch for bug 219873 fixes this bug. Can someone provide a testcase, please?
I was not very clear in my description of this issue when I first logged it. It is simply that MathML node clientWidth, clientHeight, offsetLeft & offsetTop values are incorrect.
Created attachment 450842 [details] MathML node clientWidth, clientHeight, offsetLeft & offsetTop values are incorrect
A test case is now attached
Any progress being made on this bug?
Created attachment 773306 [details] testcase for inline math A similar testcase for inline math. Here clientWidth and clientHeight are null.
MathJax's native MathML mode currently has to add some <span> or <mrow> elements around the <math> to get the correct width.
Why? getBoundingClientRect works correctly, right? In any case, per spec, offset* are only on HTML elements (which is good, because their definition is very HTML-specific and they return incorrect values anyway because they round to integers). client* are on all elements, but the spec requires them to be 0 for inline CSS boxes, which is presumably what most math stuff is. And again, it would return incorrect values if used.
So actually the MathJax code tries with offsetWidth and scrollWidth (not clientWidth). But I've also been wondering why MathJax does not just use getBoundingClientRect so I'll ask to Davide on the MathJax issue tracker.
scrollWidth is defined on all elements, but the definition assumes CSS layout...
getBoundingClientRect won't do what you want for elements inside transforms. But I'm sure you can use getBoxQuads to do whatever you need.
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #15) > getBoundingClientRect won't do what you want for elements inside transforms. > But I'm sure you can use getBoxQuads to do whatever you need. Yup, thanks roc. I am happy to close this if nobody has any objections.
I think the values are only used for MathJax zooming (but there are some hacks to try to correct the errors in values, IIRC). However the zooming will obviously not be important for the TeX-to-MathML server-side conversion on Wikipedia. The following add-on should address the problems for other websites when MathJax is used client-side: https://addons.mozilla.org/en-US/firefox/addon/mathjax-native-mathml/ https://addons.mozilla.org/en-US/firefox/addon/mathml-zoom/
Changing the MathJax dependency, since this is really an issue regarding the Zoom UI and not a bug in Gecko's MathML rendering. https://github.com/mathjax/MathJax/blob/master/unpacked/jax/output/NativeMML/jax.js#L433