Open Opened 13 years ago Updated 7 years ago

# MathML node clientWidth, clientHeight, offsetLeft & offsetTop values are incorrect

x86
Windows Vista
Not set
normal

NEW

## Attachments

### (2 files)

 2.56 KB, application/xhtml+xml Details 1.73 KB, text/html Details
User-Agent:       Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; WOW64; Trident/4.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.21022; OfficeLiveConnector.1.3; OfficeLivePatch.0.0; .NET CLR 3.5.30729; .NET CLR 3.0.30618)
Build Identifier: Gecko/2009042316 Firefox/3.0.5

MathML nodes expose their rendered x & y positions accurately using node.getBoundingClientRect() but offsetWidth and offsetHeight are undefined.

If it is possible to get the x & y positions that the MathML nodes are rendered on a page it should also be possible to get the width and heights of those nodes.

Reproducible: Always

Steps to Reproduce:
Using Javascript attempt to obtain a MathML nodes offsetWidth and offsetHeight, they will be undefined.
Actual Results:
node.offsetWidth and node.offsetHeight are undefined

Expected Results:
offsetWidth and offsetHeight should contain the rendered width and height of the MathML nodes.
See Firebug bug 1725 (http://code.google.com/p/fbug/issues/detail?id=1725)
as to why this bug should be fixed.
Whiteboard: [firebug-p3]
reassigning somewhere more appropriate, hopefully.
Component: General → MathML
Product: Firefox → Core
QA Contact: general → mathml
> 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.
Summary: MathML elements rendered x & y position available but width and height undefined → MathML node clientWidth, clientHeight, offsetLeft & offsetTop values are incorrect
A test case is now attached
Status: UNCONFIRMED → NEW
Ever confirmed: true
Any progress being made on this bug?
(In reply to Joe Java from comment #7)
> Any progress being made on this bug?

(see the remark I left in bug 667567 comment 5)

Maybe Andrii Zui can work on this during his GSoC project as it is related to MathML and javascript. However, there is no guarantees because he already has many bugs to work on.

Personally, I have no ideas how clientWidth, clientHeight, offsetLeft and offsetTop are determined. So someone who really wants to see this bug fixed should do the investigation and submit patches...
CC'ing Andrii
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 [itex] 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.
Flags: needinfo?(fred.wang)
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.
Flags: needinfo?(fred.wang)
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/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