User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0

Steps to reproduce:

Just type normally in the task's description field

Actual results:

Typing feels sluggish, with keystrokes only showing up split seconds later, just as if some heavy processing went on after entering each key

Expected results:

Keystrokes should be processed swiftly, without any processing that the user didn't ask for. It's basically a textarea widget, so what non-trivial processing needs to be done here?

WORKSFORME Characters appear as fast as I type. Same speed as when typing in the email composer.

In case a specific configuration is causing this, please post that specific configuation option that is causing it (only that one option, not all your options), so that we can reproduce it.

I looked for specific details about what might be causing this, and I noticed that the only difference is:

• on the PC where it still works all right, I've got thunderbird 78.14.0,
• whereas on the PC where it feels sluggish, I have 91.5.0

I am using TB 91.5 and TB trunk and it works fine.

I see no difference between the mail composer and editing a task.

If you have a reliable reproduction (setting, editing a specific task content etc), you can re-open.

It's more obvious on tasks whose description is rather large.

Iirc, we have a couple of occasional reports about high CPU and reduced responsiveness in different contexts and corners of TB. E.g. bug 1735340. It's not easy to track those down, as it may depend on dozens of factors, even factors outside Thunderbird.

Please give a reproduction with specific steps, as described on https://secure.phabricator.com/book/phabcontrib/article/reproduction_steps/

Agreed. The calendar component in general has been very slow for me, since many years, but not directly, but indirectly: It made even the mail composer slow and mail viewer slow. The factor I could see was the length how long the Thunderbird process was running. Once I restarted, it was fast. After 1 weeks, it became slow. So, this slowness is likely not related to this specific feature.

Given that we use the full editor for calendar and task entries now (so you get bulleted lists etc), the same editor that we use for composing mail, you might see the same effects now. But that's still unrelated to this feature, but a consequence of other bugs elsewhere.

(comment updated)

Adding some more symptomatically similar bugs - not saying they are related.

I don't think those are related. Those have a specific cause for the CPU load which is unrelated to your problem.

(In reply to Ben Bucksch (:BenB) from comment #10)

I don't think those are related. Those have a specific cause for the CPU load which is unrelated to your problem.

I agree. And progress meter is very easy to test, just by removing status bar from the view. And there are many other performance bugs - it's not practial to link them all.

Hi Alain, thank you for reporting this bug. I know you have been reporting bugs with us for more than a decade, which is appreciated! We are not refusing what you are describing. It's just that Ben believes that this is unlikely to be limited to editing tasks descriptions only/specifically, as it's more likely caused by other factors. In terms of bug management, it's important to have reproducable steps to identify the actual causes. Otherwise there's not much we could do about it. Feel free to provide more information if you have something like "reliably happens under these circumstances, but does not happen without these circumstances", or any other (preferably tested) hints in that direction. It's not easy as I said to nail these things down in a reproducable way, so no pressure and obviously we're not expecting you to dig deeper than you're willing and able to.

(In reply to Thomas D. (:thomas8) from comment #12)

Hi Alain, thank you for reporting this bug. I know you have been reporting bugs with us for more than a decade, which is appreciated! We are not refusing what you are describing. It's just that Ben believes that this is unlikely to be limited to editing tasks descriptions only/specifically, as it's more likely caused by other factors. In terms of bug management, it's important to have reproducable steps to identify the actual causes. Otherwise there's not much we could do about it. Feel free to provide more information if you have something like "reliably happens under these circumstances, but does not happen without these circumstances", or any other (preferably tested) hints in that direction. It's not easy as I said to nail these things down in a reproducable way, so no pressure and obviously we're not expecting you to dig deeper than you're willing and able to.

Thanks for your uplifting message. The thing is, as far as I can see, this appeared with the 91.5 release, along with all the other [task description] issues that I've been reporting today. Unfortunately, this is one of the more difficult to quantify aspects of the [task description] misbehavior, but I've got a feeling that they are somehow all related to the same code changes. The only reason why I filed separate bugs for all of them was because Ben asked me to. Possibly some of the bug reports of the other aspects make this easier to track down:

• bug #1749674 Editing task description collapses spaces
• bug #1745602 Collapsed white space in non-HTML event descriptions
• bug #1754148 [Task Description] After editing, preview shows text word-wrapped to 80 characters
• bug #1754150 [Task Description] Copy-paste from other applications into task description is erratic: text often gets weird "decorations" around it, and breaks synchronization
• bug #1754162 [Task Description] Spell Checker present, which can neither be set up correctly, nor switched off

My feeling is that this bug here (1754158) is more related to #1745602 than to the usual performance issues of lightning (which are long standing, and yes, frankly very annoying as well)

(In reply to Ben Bucksch (:BenB) from comment #10)

I don't think those are related. Those have a specific cause for the CPU load which is unrelated to your problem.

Yes (as I also hinted), but on the other hand, can we be sure that they are unrelated to the problem here? If CPU load is too high, my understanding is that every operation could get slowed down, why not task editing, too?

That said, thank you Ben for adding bug 592876 which looks like a much more likely candidate here, symptomatically similar afasics to bug 1735340 which I added first.

(In reply to Wayne Mery (:wsmwk) from comment #11)

And there are many other performance bugs - it's not practial to link them all.

Good point!