Rich text editor too busy in situations it does not expect

  • Thread starter SportWagon
  • 4 comments
  • 1,042 views

SportWagon

Premium
1,822
Canada
Punkeydoodles Corners, Ontario, Canada. (aka GT2t
For several years I have run my Firefox browser in one Linux lxc container, using a display managed by another lxc container (in a Xephyr window actually maintained by the real host).

This conflicts with some assumptions of the richtext editor. The result is severely high load on my machine, causing all sort of interface issues, primarily with the editor itself, but also more generally with any interactive actions.

I do use other sites with richtext editors, and, while I do not like them, they do not exhibit the same problem to the same degree.

Perhaps there is an easy fix to the problem, if the code is reviewed with a view to assumptions made. Or perhaps there could be a
dumb editor" option for uisers to choose.
 
Last edited:
What assumptions do you think the editor is making which is causing performance issues? What exactly are you doing in the editor when you notice problems? When did you first notice these problems? Does the problem occur in other browsers? Why do you assume the problem is with the editor's code and not a bug with Firefox, Xephyr, LXC, or your display drivers? What program is causing the high load on your machine?

The rich-text editor is an implementation of Froala (the project's homepage offers a sample version of their editor that you can use, it would be interesting to see if it happens there as well), extended by the XenForo (our forum software) developers. The editor is a complex piece of third-party software; I am not familiar with its inner workings enough to troubleshoot or debug it. If you really want to get to the bottom of it, your best option is to file a bug report upstream.

However, you are several edge-cases deep, running a browser in a complex containerized environment. You will need to make a strong case the bug is in the editor's code in order for this to get more attention. You can use the Firefox Performance profiler to dig into this further.

A plain-text version of the editor is also available, and would probably be your best option. Just click the "[]" button in the toolbar to toggle it on and off.
 
Last edited:
Hmm. Let's try plain text.

Well. That does seem to work better.

As I said, I do not have problems with the Microsoft Teams TM web site/portal rich text editor. That's why I suspect this editor. My contention would be that fixing my problem would improve things for everyone; they probably experience the business but its impact is less severe.

Sorry, I looked for something for plain text, but [] did not seem obvious.

(Somewhat similar, but not really related; I can't see how to cancel a post).

I don't recall when I first tried to post using the rich text editor. Perhaps I can track down my previous post, which would be not super-recently.


(And, with plain text, the external editor plugin which I use seems to work).
 
Last edited:
Thanks for the help.

This post is mostly to verity "plain text" is remembered. I.e. when I sign in again.

Perhaps when I encountered the problem I just accidentally activated rich text somehow.

The type of assumption I would think the editor might be making would be regarding the assumed cost of some specific type of character read or update operations. I see for a while, at least, BB code is still recognized.

I suppose I am suggesting that the toggle to/from plain text could be more obvious.
 
Last edited:
I use the plain view all the time to avoid a slew of snags with the rich text editor -- extra difficulty arranging quotes as desired, line break errors, certain unresponsive caret positions, unwanted formatting pasted from the clipboard...

Plain text is the only way to ensure a post is clean and composed exactly as desired.
 
Back