"Preview" button slows down server response even after unticked?

Question

When half-way composing the post Some more questions on Haag's theorem, I ticked the "Preview" button to check whether the Latex were written correctly. After seeing everything was fine I un-ticked the "Preview" button, but the editor/server reponse was still very slow, in fact as slow as when "Live preview" button is ticked(just for the sake of comparison, I never ticked "live preview" when composing that post). Then I submitted the post, the server response becomes infinitely slow and I had to close the tab and compose my post all over again(I forgot to categorize my question so it should return me a notification, this may or may not add to the slowness....).  

In fact I'm not sure if it's the fault of "Preview" or just a server glitch which happened to occur when I ticked and unticked the button.

Comments

That's odd... The preview button is only supposed to get a response from the server the moment it's ticked.

P.S. In case you encounter the issue again, rather than closing the tab and rewriting everything, you should be able to quickly ctrl+a ctrl+c the entire page content, and then select the relevant parts when you go about rewriting.

---

I was unable to reproduce with the exact bug, but I found that there's an oscillating MathJaX output that says "Processing output: 100%" and "Typesetting output: 100%" intermittently. Do you observe this too?

And can you still reproduce the bug? If so, could you see if the bug is reproduced even when MathJaX is not involved?

---

This is indeed very curious. For both types of preview, the server is not involved at all. The full preview checkbox calls a small javascript function, executed by your browser, which gets the actual content from the editor, puts it into a html <div> element, asks MathJax to render the math (which produces the text @dimension10 observes) and makes then this <div> visible. The live preview does something similar, but is triggered by the on-change event of the editor, so that its content is updated by every keystroke in the editor.

As I am revisiting actually the editor to implement a new feature, I will check this code in detail again. Please tell me should you observe this behavior again.

---

@dimension10 @polarkernel, thanks for the feedback.

---

@polarkernel: I didn't observe slowdown, because the editing is ordinarily always fast for me even with preview, but I did observe what I interpreted as the thing processing TeX like crazy while editing an answer (from little announcements that said "Processing math" "Typesetting math" over and over, it is happening, even as I am editing this comments with a bit of gratuitious TeX thrown in: $\alpha + \omega$, even though I never clicked preview before it happened. You should definitely be able to reproduce it, just put an equation somewhere, and you can see the annoucements of typesetting/processing appear again and again every keystroke. For me, this is fast, but I assume it is unnecessary processing caused by preview always being enabled for some reason.

---

@dimension10, 

 In case you encounter the issue again, rather than closing the tab and rewriting everything, you should be able to quickly ctrl+a ctrl+c the entire page content, and then select the relevant parts when you go about rewriting.

When I submit the post the page went completely blank and stuck, so it wouldn't work, I should've done so before submitting.

---

@JiaYiyang I see... that's quite bad. I guess the autosave feature polarkernel is developing might help with this.

---

@RonMaimon I am able to reproduce what you describe. After some investigations I have found that MathJax gets triggered by the math-plugin of the editor, which I have not written myself. It has nothing to do with the preview features. I will try to change it. Maybe it could be configured to wait x milliseconds for another key before triggering the typesetting so that it gets only involved when you stop writing for a moment.

As I am actually writing a "save/autosave draft" feature for the editor, I will try to include a solution there.