Bug 50210 – Positioning error in dynamically inserted content

• Status: RESOLVED
• Resolution: FIXED
• Component: Layout and Rendering

[Sean Hogan]

MathJax is a JS library that renders math in the browser using TeX or MathML as the source. MathJax is used on various sites, including math.stackexchange.com, where this issue was first reported.  

This issue occurs rarely, but whenever it does (such as the example URL) it always seems to be the last dynamically inserted content in a paragraph being incorrectly rendered above the top of the paragraph. The HTML and style settings seem fine, so this seems to be a Webkit rendering issue. 

To see an example:
1. Browse to http://math.stackexchange.com/questions/120/is-1-a-prime-number/5735#5735
2. Wait for math rendering to complete. 
3. Look for the paragraph starting with "THEOREM 28". Above the paragraph is the math R/N. This should be at the end of the paragraph. 

The math can be forced into its correct position in several trivial ways that do not change the content or styles. For example, the following bookmarklet, which merely clears and restores the left position of a suitable element, forcing a reflow in between.

javascript:(function(el) { var x = el.style.left; el.style.left = ""; el.offsetLeft; el.style.left = x; el.offsetLeft; })(document.querySelector("#MathJax-Span-184").parentNode); void(0);

[Sean Hogan]

I've created a reduced test-page. You can try it at:
http://playground.meekostuff.net/MathJax-test/shogun70/master/issue24.html?script=%2FMathJax%2Fmathjax%2Fmaster%2FMathJax.js&run=Run

Make sure your browser window is wider than 640px, which is the max-width of the container for the test paragraph. 

You can force the misplaced content into the right position merely by resizing the window width to be less than the max-width of the container. 

Interestingly this error only seems to occur when the content is the last dynamically generated in the paragraph, and the first content on a new line, and even then there must be other conditions required.

[Alexey Proskuryakov]

I've tried for a while to reduce this, but the test is still way too complicated to be useful. It may be a general dynamic relayout issue, or it could be specific to external fonts not triggering relayout correctly.

Interestingly, this problem doesn't occur on the test case if I change user agent to Firefox - the code has lots of special cases for various browsers. But the issue seems a genuine WebKit bug nonetheless.

[Alexey Proskuryakov]

Created attachment 78650 [details]
partial reduction

[Alexey Proskuryakov]

My reduction is in inner-html.html - this is source after processing TeX, and after removing all but one <script type="math/tex"> blocks. It still relies on all support files in the directory.

[Elliott Sprehn]

Whatever the issue was it's since been fixed in the layout engine since the test case and example page both don't show the issue anymore.