992127 - Add a LaTeX-to-MathML dialog box to the mail composer

Status: RESOLVED FIXED

(Thunderbird :: Message Compose Window, defect)

Description

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

Follow-up of bug 986839. Per bug 986839 comment #9, this would only be porting the editorOverlay changes. So let's try it.

(In reply to [e-mail] from comment #9)
> It depends on what you mean by reusing the parser. Simply porting the
> editorOverlay changes should allow you to get the insert mathml dialog in
> Thunderbird compose for instance (it already seems to work in SeaMonkey
> message compose), so if somewhere under editor sounds reasonable, perhaps
> editor/texzilla/ or editor/ui/texzilla/content/ could work.

Comment 1

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

Attachment: Patch

This patch applies on top of the one from bug 986839.

It seems that I have to explicitly mention TeXZilla.js in the jar.mn. I don't know if there is a better way to do that.

Note: as indicated on bug 986839, opening the math dialog might be very slow in debug mode.

Comment 2

[[e-mail]]

(In reply to Frédéric Wang from comment #1)
> It seems that I have to explicitly mention TeXZilla.js in the jar.mn. I
> don't know if there is a better way to do that.

You accidentally included TeXZilla.js in an #ifdef MOZ_SUITE block in editor/ui/jar.mn (sorry I didn't notice that before either).

Comment 3

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

Attachment: Patch V2

(In reply to [e-mail] from comment #2)
> (In reply to Frédéric Wang from comment #1)
> > It seems that I have to explicitly mention TeXZilla.js in the jar.mn. I
> > don't know if there is a better way to do that.
> 
> You accidentally included TeXZilla.js in an #ifdef MOZ_SUITE block in
> editor/ui/jar.mn (sorry I didn't notice that before either).

Ah, you're right. Good catch.

Comment 4

[Magnus Melin [:mkmelin]]

I don't know what's wrong, but the dialog repeatedly takes about 15s (!!) to open on this machine, which is reasonably fast (builds tb in about 20-25min).

Comment 5

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

(In reply to Magnus Melin from comment #4)
> I don't know what's wrong, but the dialog repeatedly takes about 15s (!!) to
> open on this machine, which is reasonably fast (builds tb in about 20-25min).

Yes, I mentioned that in comment 1. That seems specific to debug mode (bug 986839 comment 12).

Comment 6

[Magnus Melin [:mkmelin]]

This isn't a debug build, but i do have --disable-optimize

Comment 7

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

(In reply to Magnus Melin from comment #6)
> This isn't a debug build, but i do have --disable-optimize

OK, that might be the reason. As I indicate on bug 986839, the TeXZilla.js parser is big and loading it from the XUL window seems to take a lot of time (I'm not sure why). The workaround I found was to create an <iframe> in the XUL window and to load TeXZilla.js from that iframe, then opening the window was fast. But I finally removed that iframe to address review comments and because it turned out to only happen in debug build for me.

Comment 8

[[e-mail]]

I asked bz about that and he said that the difference might be that JavaScript in HTML is only initially parsed for syntax errors and not fully compiled until it is called.

Comment 9

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

(In reply to [e-mail] from comment #8)
> I asked bz about that and he said that the difference might be that
> JavaScript in HTML is only initially parsed for syntax errors and not fully
> compiled until it is called.

OK, thanks for the info. If that's a problem, we can probably keep an invisible iframe to just load TeXZilla.js and execute the TeXZilla code in that iframe document instead.

Comment 10

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

Attachment: Use an iframe

Here is a patch to load TeXZilla in an iframe, so that the window opens faster in non-optimized builds.

Comment 11

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

So what do you think? Should we take something like attachment 8405466 [details] [diff] [review] to speed up the opening of the math window in non-opt builds?

Comment 12

[Magnus Melin [:mkmelin]]

Comment on attachment 8405466 [details] [diff] [review]
Use an iframe

Review of attachment 8405466 [details] [diff] [review]:
-----------------------------------------------------------------

Yes, I think something like this is needed. 
Even with an opt build opening the dialog was around 3-4 secs, which is too long

Comment 13

[Magnus Melin [:mkmelin]]

Comment on attachment 8401786 [details] [diff] [review]
Patch V2

Review of attachment 8401786 [details] [diff] [review]:
-----------------------------------------------------------------

This is fine by me, if the load time issue gets resolved.

Comment 14

[[e-mail]]

Comment on attachment 8405466 [details] [diff] [review]
Use an iframe

It's definitely much slower than I remember it being during testing, which is odd. According to a random break into the debugger it's spending lots of time cloning the function object which is saved between invocations of the dialog supposedly to improve performance.

However I think the subscript loader would be a better way to resolve the problem (normally I would suggest a module but there are some DOM accesses which would be harder to implement in a module).

(Also in testing it occurred to me that \frac {-b \pm \sqrt {b^2 - 4ac}} {2a} might have been a better example ;-)

Comment 15

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

Attachment: subscript-loader.patch

Note: you can find more examples at http://fred-wang.github.io/TeXZilla/

Comment 16

[[e-mail]]

Comment on attachment 8408545 [details] [diff] [review]
subscript-loader.patch

>+  Components.classes["@mozilla.org/moz/jssubscript-loader;1"].
>+    getService(Components.interfaces.mozIJSSubScriptLoader).
>+    loadSubScript("chrome://editor/content/TeXZilla.js");

Nit: looks slightly neater if you write it like this:

Components.classes["@mozilla.org/moz/jssubscript-loader;1"]
          .getService(Components.interfaces.mozIJSSubScriptLoader)
          .loadSubScript("chrome://editor/content/TeXZilla.js");

(It looked odd loading the script in the middle of Startup but I couldn't see an obviously better place to put it.)

Comment 17

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

Attachment: subscript-loader.patch

Address the review comment.

(In reply to [e-mail] from comment #14)
> (Also in testing it occurred to me that \frac {-b \pm \sqrt {b^2 - 4ac}}
> {2a} might have been a better example ;-)

OK, I just understood that you meant the LaTeX example at the bottom of the EdInsertMath.xul window, not the LaTeX examples you typeset for your own testing of that feature...

The rationale for that example was not to have something that has an actual mathematical meaning, but just a short text to show some basic constructions: subscript, superscript, fraction, square root, sum and greek letter. It was perhaps not clear, but it also shows that one can enter Unicode character directly instead of backslashed symbol names. And also, I think the quadratic example has already  been overused :-)

Comment 18

[[e-mail]]

(In reply to Frédéric Wang from comment #17)
> I think the quadratic example has already  been overused :-)

Very good points, especially that last one!

Comment 19

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/comm-central/rev/b1d860289be9
https://hg.mozilla.org/comm-central/rev/d619fe2d8921

Comment 20

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

Change documented on MDN:
https://developer.mozilla.org/en-US/docs/Web/MathML/Authoring#MathML_in_email_and_instant_messaging_clients
https://developer.mozilla.org/en-US/docs/Web/MathML/Authoring#Input_Box

Comment 21

[aleth [:aleth]]

Shouldn't this also be added to the dropdown on the "Insert" button in the Compose window?

Comment 22

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

(In reply to aleth from comment #21)
> Shouldn't this also be added to the dropdown on the "Insert" button in the
> Compose window?

I guess it depends whether we consider math important enough to be added there (not all the commands of the insert menu are available in the toolbar). If we do, then we can probably open a new bug for that.