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

[Math Processing Error] with empty mmultiscripts in Native MathML mode #486

Closed
fred-wang opened this issue May 29, 2013 · 11 comments

Comments

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

commented May 29, 2013

 <math><mmultiscripts></mmultiscripts></math>

leads to a [Math Processing Error] with the Native MathML mode. This is invalid MathML but normally MathJax should pass it to the browser and let the native MathML code handle the error.

dpvc pushed a commit to dpvc/MathJax that referenced this issue May 29, 2013

@dpvc

This comment has been minimized.

Copy link
Member

commented May 29, 2013

The issue486 branch of my fork of MathJax includes a fix.

@fred-wang

This comment has been minimized.

Copy link
Contributor Author

commented May 30, 2013

OK, looks good. A quick look at the source shows that a similar processing error will happen with

 <math><munder></munder></math>
 <math><mtable><mlabeledtr></mlabeledtr></mtable>

so that would be good to fix them too while we are there.

@fred-wang

This comment has been minimized.

Copy link
Contributor Author

commented May 30, 2013

Crashtests/issue486.html

=> In testsuite

@dpvc

This comment has been minimized.

Copy link
Member

commented May 30, 2013

OK, I'll look into the other cases.

@fred-wang

This comment has been minimized.

Copy link
Contributor Author

commented Jun 12, 2013

=> Ready for release.

dpvc pushed a commit that referenced this issue Jul 31, 2013

@fred-wang

This comment has been minimized.

Copy link
Contributor Author

commented Aug 2, 2013

It seems that closing the issue increase the progress in the "Milestone" bar. Should we leave open issues marked "merge" (I don't remember why we waited the last minute before closing everything in the past)

@dpvc

This comment has been minimized.

Copy link
Member

commented Aug 2, 2013

The reason we had left them before was that it was easier to see at a glance what was actually going to be part of v2.2. This was before we had the labels for versions. Now that we have milestones, that probably isn't necessary. I think it is OK to close the issues when merged, and will start to do so.

@dpvc dpvc closed this Aug 2, 2013

@fred-wang

This comment has been minimized.

Copy link
Contributor Author

commented Aug 2, 2013

What about the "Merged" label. Is it still necessary?

@pkra

This comment has been minimized.

Copy link
Member

commented Aug 2, 2013

I'll create a "final" issue for the release (increasing versions, packing etc). That would prevent the milestone from closing automatically after technical bugs are closed -- and remind us to do the versions and packaging ;) .

@dpvc

This comment has been minimized.

Copy link
Member

commented Aug 2, 2013

I guess the merged label isn't really needed.

For the final issue, please include registering with Bower.

@pkra

This comment has been minimized.

Copy link
Member

commented Aug 2, 2013

Done.

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.