653024 - Slowness with over 10K recipients in To/From

Status: RESOLVED DUPLICATE of bug 619493

(Thunderbird :: Message Reader UI, defect)

Description

[Zack Zatkin-Gold]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/11.0.696.57 Safari/534.24
Build Identifier: 

I was opening an e-mail (a junk e-mail, to be specific) which contained over 10K recipients and it was stalling Thunderbird.

Reproducible: Always

Steps to Reproduce:
1. Open an e-mail with over 10K recipients


Expected Results:  
Manage the e-mail more effectively and be faster

I don't know if this really should be considered a bug, I am reporting this in case it is an issue that maybe should be addressed.

Comment 1

[rsx11m]

To some extent it's a known issue, but one that at this time likely cannot be done much about. The redesign of the header list as performed by bug 550487 and its follow-ups requires to effectively calculate the size of each address that it occupies in the header before the cut-off for one or more lines is reached. A special case is showing all addresses by default or after the "more" button is hit, in which case bug 560695 introduced a quicker handling by bypassing that counting, but this can't be done for the 1-line or n-line views.

Since it looks like a hang, maybe there are options to speed up things, but I'm afraid this will depend on solving the underlying XUL core issue of calculating sizes in a wrapped context correctly.

I'm reducing the severity from "critical" (which is reserved for data-loss bugs and crashes) to "major", given that Thunderbird recovers after a while. It just takes long enough to make it appear non-responsive.

Comment 2

[Zack Zatkin-Gold]

This is also a very unlikely reproducible bug, since I don't see e-mails containing 10K recipients every day.

Thanks for the response though.

Comment 3

[rsx11m]

Yes, that's indeed an unusual size. The performance issue is noticeable already with "smaller" messages containing something like 100+ recipients. Since the delay occurs when initially opening the message, it looks like Thunderbird hangs whereas it's just busy. If it were possible to defer certain actions like filling of address nodes, etc., to when expanding the full list, the user would expect a delay when seeing "9835 more" in the list. Thus, it appears there is still room for improvement even with the current XUL limitations.

Comment 4

[Ben Bucksch (:BenB)]

> 1. Open an e-mail with over 10K recipients

*cough*

*If* we were to fix this, with the current implementation, I would just count the number of addresses (i.e. array length) and if there're more than CrazyNumber (e.g. 100), use only the first CrazyNumber for calculation and show the others as "and 5623 more".

(Common one, the one who sent this mail should be sued for attempt of DoS attacks.)

Comment 5

[Ben Bucksch (:BenB)]

s/Common one/come on/

Comment 6

[Wayne Mery (:wsmwk)]

why is this not a dup of bug 619493?  

(it is unfortunately at tad hidden in backend component)

Comment 7

[rsx11m]

It probably is (didn't find it when searching), but unless that bug is covering a real backend/database issue (".msf" files?) it should be moved to the respective Thunderbird Message Reader UI component.