News for hackers. Stuff that matters.
Re:Improving Firefox Responsiveness on macOS by babypuncher on Monday October 10, 2022 @04:44PM (#33156203)
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.

Re:Improving Firefox Responsiveness on macOS by gsvelto on Monday October 10, 2022 @05:05PM (#33156379)
If 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.
Re:Improving Firefox Responsiveness on macOS by babypuncher on Monday October 10, 2022 @05:34PM (#33156656)
I'll try to get on that this week sometime
Re:Improving Firefox Responsiveness on macOS by kibwen on Monday October 10, 2022 @07:30PM (#33157600)
Is 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.
Re:Improving Firefox Responsiveness on macOS by 3836293648 on Monday October 10, 2022 @08:05PM (#33157858)
No, I've heard of people using it for years. They probably just moved it to make it more visible
Re:Improving Firefox Responsiveness on macOS by BeefWellington on Monday October 10, 2022 @08:25PM (#33158005)
The 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.
Re:Improving Firefox Responsiveness on macOS by kibwen on Monday October 10, 2022 @09:06PM (#33158275)
Ah, 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.
Re:Improving Firefox Responsiveness on macOS by depr on Tuesday October 11, 2022 @07:13AM (#33161892)
That also exists, see https://profiler.firefox.com

I am sure Mozilla would appreciate a bug filed in Bugzilla if you can.

Re:Improving Firefox Responsiveness on macOS by sfink on Tuesday October 11, 2022 @05:43PM (#33169624)
There 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.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 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.)

Re:Improving Firefox Responsiveness on macOS by lawgimenez on Monday October 10, 2022 @07:54PM (#33157793)
There is also a lot of catching up to do on Firefox iOS. It is still crashing on heavy and large websites (government websites in my country) and then the more I used it, the more it lags and taking down the whole iOS system.
Re:Improving Firefox Responsiveness on macOS by KptMarchewa on Monday October 10, 2022 @08:18PM (#33157954)
On iOS it's the same engine safari uses.
Re:Improving Firefox Responsiveness on macOS by cpeterso on Monday October 10, 2022 @04:58PM (#33156317)
Is 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/

Re:Improving Firefox Responsiveness on macOS by skybrian on Monday October 10, 2022 @05:06PM (#33156386)
Have you looked at ProseMirror and Quill? I'm wondering how they compare.
Re:Improving Firefox Responsiveness on macOS by babypuncher on Monday October 10, 2022 @06:18PM (#33157046)
I 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.

Re:Improving Firefox Responsiveness on macOS by nicoburns on Monday October 10, 2022 @08:23PM (#33157991)
Do 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.

Re:Improving Firefox Responsiveness on macOS by hamandcheese on Monday October 10, 2022 @11:08PM (#33159063)
> 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?

Re:Improving Firefox Responsiveness on macOS by laundermaf on Tuesday October 11, 2022 @01:36AM (#33159842)
> 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.

Re:Improving Firefox Responsiveness on macOS by girvo on Tuesday October 11, 2022 @01:48AM (#33159903)
https://ckeditor.com/blog/ContentEditable-The-Good-the-Bad-a...

Or

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?

Re:Improving Firefox Responsiveness on macOS by laundermaf on Tuesday October 11, 2022 @02:08PM (#33166777)
Ah 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.

Re:Improving Firefox Responsiveness on macOS by faebi on Tuesday October 11, 2022 @03:33AM (#33160413)
I‘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.
Re:Improving Firefox Responsiveness on macOS by kennydude on Tuesday October 11, 2022 @08:38AM (#33162624)
Advanced 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,