Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hang with root containing mspace with very large height #366

Closed
fred-wang opened this issue Dec 20, 2012 · 13 comments

Comments

Projects
None yet
2 participants
@fred-wang
Copy link
Contributor

commented Dec 20, 2012

The following code makes MathJax hang (tested with Chrome, Firefox ; HTML-CSS output):

  <math>
      <msqrt>
        <mspace height="50000em"></mspace>
      </msqrt>
  </math>
@fred-wang

This comment has been minimized.

Copy link
Contributor Author

commented Dec 20, 2012

I guess this has something to do with the drawing of stretchy symbols when size is very large. For example, this also happens with a ( next to the mspace.

@dpvc

This comment has been minimized.

Copy link
Member

commented Dec 20, 2012

Well, MathJax does have to make the stretched vertical component out of small vertical segments, and so it will have to make a huge number of them in order to cover the 50,000em space. Since the vertical segment is less than 1em in height (as I recall), that means over 50,000 separate pieces. That will take a while. So I suspect MathJax isn't actually hung, but is just making all those parts and putting them together (it may be getting slower and slower as it goes).

Perhaps 50,000em it too much to expect.

@dpvc

This comment has been minimized.

Copy link
Member

commented Dec 20, 2012

I just ran a test by hand in Safari, and it takes about 12 seconds to generate the square root. But it does eventually do it.

@fred-wang

This comment has been minimized.

Copy link
Contributor Author

commented Dec 20, 2012

OK, these sizes will certainly not happen in practice, but I guess we should prevent that e.g. someone puts LaTeX code like

\left( \Space{0em}{50000em}{0em} \right)

in a blog comment or in Wikipedia in order to hang the visitors' browsers (at least during a few seconds). Perhaps we should limit the number of iterations for stretchy symbols?

@dpvc

This comment has been minimized.

Copy link
Member

commented Dec 20, 2012

Probably worth doing. The number of pieces is calculated up front, so we could put a cap on that.

I just tested Firefox and it was about 30 seconds. Chrome is still running; I have suspected it of having memory management issues, and this might be coming into play here.

@dpvc

This comment has been minimized.

Copy link
Member

commented Dec 20, 2012

It took about 45 seconds for Chrome to do 5,000 em, and it has been going up super-linearly, so I expect 50,000 em would be too long to wait. If I recall correctly, the fix for the alignment problem in Chrome (where I changed to pixels instead of em's) required an additional use of offsetHeight when any element is explicitly positioned, as is done with the segments that make up the stretchy characters. Since that forces a reflow, that probably accounts for the rapidly growing delay in Chrome. Probably worth doing something about that (perhaps suspending the offset lookup during delimiter creation).

@fred-wang

This comment has been minimized.

Copy link
Contributor Author

commented Dec 26, 2012

This issue happens in other situations with large content, for example I just found it again with a large mathsize. I've added a quick workaround in my issue366 branch, so that I'll be able to continue my tests:

b7bf3be

This issue does not happen with the SVG output (although some gaps are visible as soon as the size of the stretchy operator is large enough, e.g 20em).

@fred-wang

This comment has been minimized.

Copy link
Contributor Author

commented Jan 5, 2013

Crashtests/issue366.html

=> In testsuite

@fred-wang

This comment has been minimized.

Copy link
Contributor Author

commented Feb 6, 2013

Coming back to this, I'm wondering if it's worth adding a configuration option for that, or if using a hardcoded value of 1000 as in the commit above is fine?

@dpvc

This comment has been minimized.

Copy link
Member

commented Feb 6, 2013

Well, perhaps making it be a property of the HTML-CSS jax (e.g, HTMLCSS.maxDelimExtensions) would make it something that could be overridden if needed without requiring it to be a configuration option that needs a lot of documentation.

@dpvc

This comment has been minimized.

Copy link
Member

commented Mar 20, 2013

I think you are right to make this a value that can be modified. Do you think HTMLCSS.maxDelimExtensions would work for that?

@fred-wang

This comment has been minimized.

Copy link
Contributor Author

commented Mar 21, 2013

Yes, I added a property in a subsequent commit (although I called it maxStretchyParts):

https://github.com/fred-wang/MathJax/compare/master...issue366

@dpvc

This comment has been minimized.

Copy link
Member

commented Mar 21, 2013

Sorry, missed that. I only saw the one commit above and didn't realize there was a second. I guess I should use the network diagram and the comparison page more frequently. I'll merge it into develop.

dpvc pushed a commit to dpvc/MathJax that referenced this issue Mar 21, 2013

@dpvc dpvc closed this May 17, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.