MathJax rendering \bk differently in question display and edit modes

Question

I'm completely stumped by this. The question Enegy Expectation Value uses the LaTeX command \bk, which is definitely not a standard LaTeX command. Quite fittingly, it fails to display correctly on the question page.

Seeing this, I clicked on the edit button to fix that LaTeX, but to my great surprise I was met by this:

Note, in particular, that the \bks evaluate as bra-ket pairs.

---

I will go ahead and change this into more standard LaTeX, as there exist devices on which this fails to display correctly, but I'm more interested in why and how on Earth this happened. Evidently the display and edit pages are calling different instances of MathJax, but how come they support different command sets? This strikes me as a bug (the OP here thought it would display correctly and it didn't), for one, but more than fixing it I'm interested in any details of the back end that are responsible for this behaviour.

I'm running Google Chrome 47.0.2526.80 (64-bit) over Ubuntu 14.04.

---

Edit

Aha, Sebastian Riese points out that the responsible line,

$$\newcommand{\bk}[1]{\left\langle #1 \right\rangle}$$

needs to be at the top of the post for this to work on question display mode. This is definitely the expected behaviour, and I'm confused as to why the edit mode thinks it's OK. Maybe it's running MathJax multiple times over the post, and picking up definitions for the next round? This strikes me as buggy behaviour, to be honest.

Answer 1

My guess is the following:

1. When you first view the question, the MathJax processor goes through the page rendering math, encountering several instances of \bk which it doesn't recognize, and renders them as errors, as you'd expect.
2. Then it gets to the \newcommand, which adds \bk into the list of recognized macros.
3. Then when you go to edit the post, what happens is that Stack Exchange's Javascript constructs the text box and an empty preview pane and inserts them into the page in place of the question.
4. Then another piece of Javascript runs which interprets the contents of the textbox as Markdown, converts it to HTML, and inserts the resulting HTML into the preview pane.
5. That script triggers another run of the MathJax processor, this time only operating on the contents of the preview pane (i.e. the rendered HTML from the previous step). Since the page hasn't been reloaded, the macro definitions from the original page (before you started editing) are still in effect, and thus the MathJax processor is able to render \bk to a braket.

If you want to check this, go to a question (or start writing a new question) and define some MathJax macro with \newcommand, wait for the preview to update, and then remove the \newcommand macro from the text of the post and let the preview update again. Your definition should still be in place. (In this example, if you remove the \newcommand{\bk}{...} and let the preview update, you will still see the \bks rendered as brakets. Of course actually submitting that edit will make them show up as errors.)

I'm not sure whether to consider this a bug, because it exceeds the scope of where MathJax is meant to be used, namely static pages where the MathJax processor runs once, or at the most, live-update pages where content is added on at the end, not replaced in the middle of the page. But on the other hand, it is undesirable behavior. The fix is conceptually straightforward; SE would have to adjust their preview function so that any definitions made within the post itself are "sandboxed", and cleared out each time the preview refreshes. It's probably easier said than done, though I'm not sure how much easier.