491668 - MathML node clientWidth, clientHeight, offsetLeft & offsetTop values are incorrect

Status: NEW

(Core :: MathML, defect)

Description

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

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.

Comment 1

[Joe Java]

See Firebug bug 1725 (http://code.google.com/p/fbug/issues/detail?id=1725)
as to why this bug should be fixed.

Comment 2

[Rob Campbell [:rc] (:robcee)]

reassigning somewhere more appropriate, hopefully.

Comment 3

[Frédéric Wang (:fredw)]

> 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?

Comment 4

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

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.

Comment 5

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

Attachment: MathML node clientWidth, clientHeight, offsetLeft & offsetTop values are incorrect

Comment 6

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

A test case is now attached

Comment 7

[Joe Java]

Any progress being made on this bug?

Comment 8

[Frédéric Wang (:fredw)]

(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...

Comment 9

[Frédéric Wang (:fredw)]

CC'ing Andrii

Comment 10

[Frédéric Wang (:fredw)]

Attachment: testcase for inline math

A similar testcase for inline math. Here clientWidth and clientHeight are null.

Comment 11

[Frédéric Wang (:fredw)]

MathJax's native MathML mode currently has to add some <span> or <mrow> elements around the <math> to get the correct width.

Comment 12

[Boris Zbarsky [:bzbarsky]]

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.

Comment 13

[Frédéric Wang (:fredw)]

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.

Comment 14

[Boris Zbarsky [:bzbarsky]]

scrollWidth is defined on all elements, but the definition assumes CSS layout...

Comment 15

[Robert O'Callahan (:roc) (email my personal email if necessary)]

getBoundingClientRect won't do what you want for elements inside transforms. But I'm sure you can use getBoxQuads to do whatever you need.

Comment 16

[Mike Ratcliffe [:miker] [:mratcliffe] [:mikeratcliffe]]

(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.

Comment 17

[Frédéric Wang (:fredw)]

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/

Comment 18

[Frédéric Wang (:fredw)]

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