Add support for trapping and reporting sre errors.

[dpvc]

This PR adds support for trapping and reporting errors that occur during the SRE enrichment process. It adds a new enrichError(), comparable to the compileError() and typesetError() options, that allows you to capture the error and respond to it. The default is to just issue a console warning, and to use the original (unenriched) MathML, but you could use this to present a different representation, or record the message, or whatever.

This also changes the inputData that is being kept so that originalMml is the original serialization of the internal MathML, and enrichedMml is the serialized enriched MathML (which used to be stored a originalMml, which doesn't seem right). No other component currently uses this data, so it should be OK to make this change.

[zorkow]

The problem with this approach is that only works in the case where SRE actually fails to return something. If it returns valid something that cannot be rendered, then the menu fails on opening due to the cs preferences.

[zorkow]

Replacing lines

MathJax-src/ts/a11y/explorer.ts

Line 598 in 5e238af

const items = sre.ClearspeakPreferences.smartPreferences(

to

MathJax-src/ts/a11y/explorer.ts

Line 606 in 5e238af

}, sub);

by

  let items = null;
  try {
    items = sre.ClearspeakPreferences.smartPreferences(
      menu.mathItem, locale);
    if (box) {
      items.splice(2, 0, box);
    }
  } catch (e) {}
  return menu.factory.get('subMenu')(menu.factory, {
    items: items || [],
    id: 'Clearspeak'
  }, sub);

will take care of the problem.

In the future this should really be caught in SRE and/or the context menu not here. But it will work as a temporary fix here.

[dpvc]

I'm not sure I understand what you are saying, but am happy to add the code you suggest. One question, though: The current code (without your new try statement) performs the smartPreferences() call, the conditional item.splice() and the menu.factory.get() call, but with the try you get either just the first two, or just the last one, but not both. Is that what is intended?

[zorkow]

I note, my sentence was incomplete. Sorry, fatigue.
I meant "if SRE returns valid enriched markup, but that cannot be rendered", e.g., due to a third party parser (my use case was the xypic extension) then there is an error in SRE that is currently not being caught.

I originally thought that if the smart preferences fail, there is really no need to compute the selection preferences. But in hindsight this is probably not smart, as they could fail on non-error elements as well. So I suggest this:

let csMenu = function(menu: MJContextMenu, sub: Submenu) {
  let locale = menu.pool.lookup('locale').getValue() as string;
  const box = csSelectionBox(menu, locale);
  let items: Object[] = [];
  try {
    items = sre.ClearspeakPreferences.smartPreferences(
      menu.mathItem, locale);
  } catch (e) {}
  if (box) {
    items.splice(2, 0, box);
  }
  return menu.factory.get('subMenu')(menu.factory, {
    items: items,
    id: 'Clearspeak'
  }, sub);
};

[dpvc]

if SRE returns valid enriched markup, but that cannot be rendered, e.g., due to a third party parser (my use case was the xypic extension) then there is an error in SRE that is currently not being caught.

If by "rendering" you mean by an output jax, then there is already a trap for failure to render (typesetError()), and that can be used to catch the error. But the important part is, it doesn't stop MathJax from continuing to process other math, which the SRE failure trapped here would. Without this, if SRE fails to produce a result, MathJax will crash and not finish processing the rest of the math. That is why this change is useful. (We already have that for compiling and typesetting.)

It may be that a more general solution would be useful, where each renderAction is run inside a try/catch block. Then we wouldn't need the special cases for compile/typeset/enrich. If so, we can do that for 3.2.0.

[dpvc]

So I suggest this ...

I've made the requested change.

[dpvc]

I also resolved the conflict.

[dpvc]

If you want to wait with this for v3.2 and a more general solution, I'm OK with that.

[zorkow]

Even when the rendering error is caught, the menu error might prevent you from switching off whatever has caused the rendering error. Consider the scenario

• Page with a single Math item.
• Switching on a11y via the context menu leads to Math Output Error.
• Error in the cs submenu prevents you from opening the context menu
• Now you have no way of switching off a11y short of altering the localStorage

Let's keep it in for 3.1.3 and have a good cleanup of that part for 3.2.

[zorkow]

lgtm.

[dpvc]

Let's keep it in for 3.1.3 and have a good cleanup of that part for 3.2.

OK, good enough.