4 ms·
I've been shilling for Firefox for years. It is my primary browser for both development and personal use. But I still think it has some catching up to do with C
by babypuncher 4y ago
I've been shilling for Firefox for years. It is my primary browser for both development and personal use. But I still think it has some catching up to do with Chrome.
I have a web app that allows customers to make templates for their standard operating procedures that they pull from our main product. For writing steps and substeps, I use a WYSIWYG HTML editor called TynyMCE. I went with it because I was able to implement it in an afternoon, their licensing was compatible with our use, and I had a tight deadline.
We failed to anticipate just how large some of the templates clients would be making, so sometimes when they open a template they end up having a couple hundred of these editors hidden behind drag and drop enabled accordions.
Firefox chokes on the initial TinyMCE calls for these large templates, taking quite a long time to fully render the page. Once it's done, everything is nice and snappy, but it's like a 20-30 second wait after the wire even on my beefy 5900x.
Chrome seems to handle this just fine.
It's possible that the culprit is a bad polyfill or a Firefox-specific bug in TinyMCE, I haven't put much work into diagnosing it yet beyond verifying that TinyMCE is eating up all the CPU time. For now my planned solution is to just write my own WYSIWYG editor, because TinyMCE ultimately offers a lot more than we actually need, and it was only a stopgap solution to get out a polished MVP. But needless to say, for the first time in years, I found myself spending a non-trivial amount of development time in Chrome. Sadly I've never actually had a client use this app with anything other than Chrome or Safari, so this is naturally a low-priority issue.
- deleted 4y ago[deleted]
- cpeterso 4y agoIs there a public demo or test page for TinyMCE that reproduces the hangs? If not, you could use Firefox's built-in performance profiler to record a profile and file a Firefox bug. Here are instructions of using the profiler with just a few clicks: https://profiler.firefox.com/ https://profiler.firefox.com/
- gsvelto 4y agoIf you could grab a profile of the problem with the Firefox profiler and file a bug it would be greatly appreciated. From the sounds of it it's probably an edge-case we're not aware of where Firefox performs very poorly. The problem with this kind of things in Mozilla is that we're often blind until someone brings up the issue and notifies us.
- babypuncher 4y agoI'll try to get on that this week sometime
- kibwen 4y agoIs the profiler a new addition? I'm on Nightly and I recently noticed the appearance of its little speedometer button in my toolbar and I'd be interested to learn more about it. The graphs it generates look nifty, but I have no idea how to interpret them.
- 3836293648 4y agoNo, I've heard of people using it for years. They probably just moved it to make it more visible
- BeefWellington 4y agoThe profiler has been there for ages. It's definitely not new. They're moving where it's accessed but it's been under the Performance tab of the developer tools for a long time.
- kibwen 4y agoAh, I'm aware of the feature in the devtools, but I thought this feature was designed to capture the performance of the browser UI itself.
- depr 4y agoThat also exists, see https://profiler.firefox.com https://profiler.firefox.com I am sure Mozilla would appreciate a bug filed in Bugzilla if you can.
- sfink 4y agoThere are two different profilers. There was one in devtools for a long time that was aimed at web content. It was pretty nice for its time, but its time was a long time ago. In a separate project, a profiler for both content and browser UI was developed—that's the one at https://profiler.firefox.com—and https://profiler.firefox.xn--comand-5g0c it has been seeing a ton of high quality work for quite a while now. At some point, it was clearly so much better that they started enabling it to optionally focus on web content (though platform stuff is still accessible if you need it). The recent change is the old devtools profiler has been put out to pasture and replaced with the newer one (with presets configured appropriately for web content), and additionally the platform profiler is more integrated so you don't need an add-on or anything; going to https://profiler.firefox.com https://profiler.firefox.com gives you the option to activate the built-in functionality. The Firefox Profiler is an amazing piece of work. It's my tool of choice even for non-Firefox scenarios, since it can load in perf profiles (and even Chrome profiles, though I haven't tried that). It has grown into a general profiler front-end, and continues to see significant improvements. I have heard of a number of people adopting it as their system profiler of choice for arbitrary workloads, not just browser-related ones. (I work at Mozilla, but not on the profiler. At least not most of the time. I've added some small things in to give it more information about my specific subsystem. I have enormous respect for the work going into the profiler, both the functionality and design.)
- skybrian 4y agoHave you looked at ProseMirror and Quill? I'm wondering how they compare.
- babypuncher 4y agoI evaluated a few different options including Quill, but this problem never would have really come up in my prototypes. The performance issues really are only apparent when you have an obnoxious number of TinyMCE editors on a single page. The reason TinyMCE won out was because they made self-hosting easy under license terms that my employer was OK with, and wrapping the whole thing in a Vue component only took me a few hours.
- nicoburns 4y agoDo you need to have them all active at once? One option could potentially be to enable instances on click and disable on blur or similar. FWIW, TinyMCE is a bit long in the tooth these days. I implemented my own from-scratch WYSIWYG editor back in 2010, and it wasn’t even the best option then (ckEditor was much better), and many people were using the unreliable lightweight jquery based editors because TinyMCE was considered too heavyweight. I wouldn’t like to say for sure that’s it’s the source of your problems (Firefox’s contenteditable implementation is also “quirky”), but it could well be.
- hamandcheese 4y ago> so sometimes when they open a template they end up having a couple hundred of these editors hidden behind drag and drop enabled accordions. What if you only loaded/initialized the editors when they became visible?
- laundermaf 4y ago> just write my own WYSIWYG editor For your own mental health, don’t. I was looking for an old article describing how bad the API is, written by one of the authors of a WYSIWYG JS editor, but I can’t find it.
- girvo 4y agohttps://ckeditor.com/blog/ContentEditable-The-Good-the-Bad-and-the-Ugly/ https://ckeditor.com/blog/ContentEditable-The-Good-the-Bad-a... Or https://medium.engineering/why-contenteditable-is-terrible-122d8a40e480?gi=d435208e3b0d https://medium.engineering/why-contenteditable-is-terrible-1... Are two that I remember reading... nearly 10 years ago, holy hell can someone please make time slow down? Which discuss the common API pitfalls with `contenteditable` -- though I've no idea how painful it is in 2022. Could be a lot better now?
- laundermaf 4y agoAh yes the second one is exactly it. > Could be a lot better now? Effectively zero progress. Last year I heard some work being done on an alternative API but I haven’t see that since. I don’t expect anything to be done before 2025 if ever.
- faebi 4y agoI‘m on the other side of that. I'm constantly throwing large amounts of HTML at Firefox and it just goes on normally, literally 0 slowdown. Add some VueJS for additional fun. I deploy and get Chrome users complaining about performance. One example is that one can not add more than a few hundred options in an Options Select list in Chrome. You can throw literally 10'000 at Firefox. Similar stuff with text fields having 10'000s of rows.
- kennydude 4y agoAdvanced Custom Fields on WordPress allows for "click to initialize TinyMCE" on areas such as that which may be a usable workaround for now. Then you only have 1 initializing at a time,