1075398 - Warning unresponsive script adressingWidgetOverlay.js:606 when more than 4000 bcc adresses and answering to all

Status: NEW

(Thunderbird :: Message Compose Window, defect)

Description

[Manfred]

Attachment: ahbifgfb.png

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:32.0) Gecko/20100101 Firefox/32.0
Build ID: 20140924083922

Steps to reproduce:

I tried to reply to all senders of an email I did sent earlier this morning (more than 4000 bcc adresses)


Actual results:

the unresponsive script message showed up.



Expected results:

the mail compose window should have opened

when there are less bcc adresses it works like a charm!

Comment 1

[:aceman]

I can see the problem here. I have filed some separate bugs that will help here (and generally).


This is mostly a regression from bug 431217 where a slow UpdateSendLock() was added that is checked after each recipient. Adding recipients from the replied message also triggers that function.

Comment 2

[Wayne Mery (:wsmwk)]

Great find. So a regression of TB23/TB24

Comment 3

[Wayne Mery (:wsmwk)]

Benjamin, can you generate a testcase for this and the 2 related bugs, from bug 619493 which has a script to generate testcase? Then we need to generate a performance profile.

Comment 4

[Wayne Mery (:wsmwk)]

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

Benjamin, can you generate a testcase for this and the 2 related bugs, from bug 619493 which has a script to generate testcase? Then we need to generate a performance profile.

Is this still reproducible with night and new AB backend?

Comment 5

[:aceman]

I still have a testcase with 4000 recipients from the times I worked on bugs related here.
These days, the recipient area changed to the pills concept so this needs new look considering the new code.
Replying to such an email takes 50 minutes just to open the compose window on a Ryzen machine, albeit with a debug build.
Then another 50 minutes after being rendered for the window to become responsive. But that may be a "feature" of the great custom elements, similar to what we see in bug 1588155.

So the "unresponsive script" warning can still happen.

Comment 6

[Alessandro Castellani [:aleca]]

Uh, interesting.
Is this testcase available on trunk? I'd like to run it locally.

Without digging to deep into the problem, here's a random idea without proper research.
When the compose dialog opens, there's a method called CompFields2Recipients() which takes care of reading the email header and converting all those addresses into pills.
https://searchfox.org/comm-central/rev/92a0cfea9653b13ea7a214f1ecdb3d988aac4f1a/mail/components/compose/content/addressingWidgetOverlay.js#101

What if we change that method into an async and we let the compose window open with the recipients area covered by an overlay with a progress bar and a message like "Importing 300 of 4000 recipients...".
In this way, the user can still interact with the identity field, subject, attachments, and message body, while the recipients are being generated in the background.
It won't solve the speed problem, as 50 seconds will always be necessary for the user to be able to interact with the recipients, but at least we prevent the application from hanging, and the user sitting there without any feedback.

Does this sound silly?

Comment 7

[:aceman]

I said 50 minutes.
I don't think we should allow the user to interact with the window in that time as he will surely try to close it and then bad things will happen :)
Interestingly, trying 300 recipients only takes a few seconds, so the slowdown isn't linear.

Comment 8

[Alessandro Castellani [:aleca]]

(In reply to :aceman from comment #7)

I said 50 minutes.

Sorry, I misread.

I don't think we should allow the user to interact with the window in that time as he will surely try to close it and then bad things will happen :)

If we decide to go this route, we can definitely have some fail safes in place. But yeah, I agree with your concerns.

Interestingly, trying 300 recipients only takes a few seconds, so the slowdown isn't linear.

That's interesting indeed. Can you slowly increase that number and see if there's a specific threshold that causes the slowdown?

Comment 9

[:aceman]

We have a nice recipient list generator in https://bug619493.bmoattachments.org/attachment.cgi?id=498664 . Paste the result into the source of a prepared message in the mbox file of a folder, then delete its .msf file and start TB :)