Open Bug 479989 Opened 15 years ago Updated 1 year ago
Input response time of "hide details" and "other actions" buttons is inappropriately impacted by size of recipient list
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090224 Lightning/1.0pre The "hide details" and "other actions" buttons, in the header block, become slow to respond when the "more" link has been clicked to reveal the full list of recipients. The degree of slow-down is proportional to the number of recipients listed. This is very noticeable on slower systems (e.g. my P3 933 MHz). For instance, I received a message that was also sent to 89 other recipients (i.e. 90 total recipients in the "to" field). After clicking "more" to expand the recipient list, the "hide details" and "other actions" buttons become significantly less responsive than they are before the list is expanded. The slow-down is less for an email with fewer recipients. Reproducible: Always Steps to Reproduce: 1. Load up Shredder on something other than your desktop version of Blue Gene/L 2. Locate an email with a very large (say 100+) recipient list 3. Enable the preview pane, if you have not already. 4. Click the message so it displays in the preview pane 5. Move your mouse pointer back and forth between the "hide details" and "other actions" buttons. Note the responsiveness. 6. Click the "more" link to expand the recipient list 7. Scroll the list to the bottom 8. Again, move your mouse pointer back and forth between the "hide details" and "other actions" buttons. Note the significant decline in responsiveness.
Gary, can you confirm this bug? Assuming that it's easily reproduced, please then nominate it to block. My suspicion is that if the current strategy of changing the (more) implementation to use the DOM instead of just CSS works, that may help here.
(In reply to comment #1) > Gary, can you confirm this bug? Assuming that it's easily reproduced, please > then nominate it to block. Sure - assigning to myself to get it on my QA radar..
Assignee: nobody → nth10sd
(In reply to comment #1) > My suspicion is that if the current strategy of changing the (more) > implementation to use the DOM instead of just CSS works, that may help here. > This is slightly OT, but could this use of CSS be the same reason why, with extensions such as JunQuilla (https://addons.mozilla.org/en-US/thunderbird/addon/9886) installed, navigating from one message to another, in the thread pane, is excruciatingly slow? I believe "Virtual Identity" (https://addons.mozilla.org/en-US/thunderbird/addon/594) is another extension that suffers this way--don't remember.
(In reply to comment #3) > > This is slightly OT, but could this use of CSS be the same reason why, with > extensions such as JunQuilla > (https://addons.mozilla.org/en-US/thunderbird/addon/9886) installed, navigating > from one message to another, in the thread pane, is excruciatingly slow? I don't know. My suggestion would be to file another bug on that topic, cc firstname.lastname@example.org (whom I've added to this bug), and then see if that problem goes away once bug 469878 is fixed.
On this note - I'm having slight problems trying to repro this - I don't have 100+ recipients in my emails, probably max out at 20 odd which doesn't show the problem. And my computers are decently faster (dual core, 2 or 4Gb ram etc.) than your P3 933 Mhz.. Any ideas?
confirming. UI's step 8 in comment 0 for me is about 1 second response to mouse over hide details and other actions 600+ addresses on message, imap folder P4 3.2GHz Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090218 Shredder/3.0b2pre PIII of course would be much slower - triple? other stuff is definitely not instantaneous, but reasonable I think open message <1 sec show details 2.5 sec more 3.5 sec hide details <1 sec mousing over addresses <1 sec
Severity: normal → minor
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: unspecified → Trunk
clicking "other actions" to seeing results (the menu) is 2 sec. Again, will probably be longer for smaller cpu
For those with fast CPUs, I have attached a sample email file containing 1,398 recipients. This should hopefully be enough to produce a noticeable slowdown. @Dan: Thanks I'll consider filing one.
(In reply to comment #8) > Created an attachment (id=364358) [details] > Sample email file to test with (1,398 recipients) > > For those with fast CPUs, I have attached a sample email file containing 1,398 > recipients. This should hopefully be enough to produce a noticeable slowdown. > > @Dan: Thanks I'll consider filing one. Excellent testcase - double confirming on Mac (C2D MBP with 4Gb ram) and nominating blocking-thunderbird3 due to its perf impact by a new feature (the message header UI is a new feature in TB3 over TB2) QA job done, deassigning. (I'd like to push it up beyond minor - the STR slow down my entire TB UI occasionally as well, when I had opened the attached testcase, but I'd leave it to Dan to decide) IU, thanks for the excellent testcase once again. :)
Assignee: nth10sd → nobody
OS: Windows XP → All
Hardware: x86 → All
1398 is such a large number as to be really pathological; this doesn't block based on that. However, it certainly could still be blocker. It would be super helpful to whittle down that test case to something that people are actually likely to see occasionally (75 addresses, maybe?). Please put together a test like that, get some results, and then re-nominate if appropriate.
Assignee: nobody → nth10sd
Severity: minor → normal
Flags: blocking-thunderbird3? → blocking-thunderbird3-
Target Milestone: --- → Thunderbird 3.0rc1
(In reply to comment #10) > ...It would be > super helpful to whittle down that test case to something that people are > actually likely to see occasionally (75 addresses, maybe?). Please put > together a test like that, get some results, and then re-nominate if > appropriate. As you can read in my original report, Comment #0, I experienced this with ONLY 90 and fewer addresses, but on a P3 933 MHz system. I also explicitly states that, " The degree of slow-down is _PROPORTIONAL_ to the number of recipients listed." Thus, there is _NO_ magical trigger number. The slowdown is less noticeable on very fast systems, which is why, because the slowdown _IS_ proportional, I attached the sample email with large recipient list--to ensure that anyone, with one of the fast systems, would notice. Therefore, while 1398 addresses might be "really pathological" it is perfectly valid; though anyone could edit the list down to determine the point where their system speed does not mask this problem.
Here's a sample email for everyone to test (cut down from IU's testcase to 75 recipients, if that's the magic number), the slowdown exists, but kind of minute and makes me doubt if it's the app or my poor response - but some slowness does occur. And pretty fragmented - mouse-ing over the UI buttons sometimes shows these slowness by probably 50 to 100ms or so - sometimes doesn't. C2D Mac btw, 4Gb ram.
eyeball profile of Gary's testcase with expanded header and moving quickly between "hide details" and "other actions" - cpu 2-3% with addresses not expanded - 10x with addresses expanded, ie. 30-40% cpu - I don't see this cpu usage when moving between buttons "reply" and "forward"
(In reply to comment #11) > (In reply to comment #10) > > As you can read in my original report, Comment #0, I experienced this with ONLY > 90 and fewer addresses, but on a P3 933 MHz system. I also explicitly states > that, " The degree of slow-down is _PROPORTIONAL_ to the number of recipients > listed." Thus, there is _NO_ magical trigger number. Right; I wasn't looking for a trigger number, but trying to make a guess at whether this is so bad in less pathological cases that it should block Thunderbird 3. Can I talk you into giving the 75 address version a shot on your 933 machine? Yeah, this is all fuzzy and somewhat arbitrary, but having some sort of quantitative feel for things is better than not at all when making such decisions, IMO.
75 addresses is still slow on my P3. Takes about 2 secs to go back-and-forth between buttons, after "more" is clicked and list is expanded. Prior to expanding, it is practically instantaneous.
Ugh; that's pretty painful. Marking as blocking and taking. Thanks for the testing! It'll be interesting to see if the fix for bug 469878 helps here.
Assignee: nth10sd → dmose
Flags: blocking-thunderbird3- → blocking-thunderbird3+
Can someone test this with recent nighlies, and see if it still occurs?
I just tried this on a PIII mobile 1.3Ghz with the 3.0b4 candidates, and while it's noticeably slower, it's not terrible. Given that it's likely to be encountered relatively infrequently, if this were the last bug standing, I don't believe we'd continue to hold Tb3 for it. Marking as blocking-.
Flags: blocking-thunderbird3+ → blocking-thunderbird3-
Target Milestone: Thunderbird 3.0rc1 → ---
Significantly improved. Used to take 2 secs for 75 addresses but is now practically instantaneous; and 400 addresses takes a little over 1 sec. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124pre) Gecko/20090916 Lightning/1.0pre ID:20090916031343 P3 933 MHz
You need to log in before you can comment on or make changes to this bug.