479989 - Input response time of "hide details" and "other actions" buttons is inappropriately impacted by many recipients

Status: RESOLVED WORKSFORME

(Thunderbird :: Message Reader UI, defect)

Description

[IU]

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.

Comment 1

[Dan Mosedale (:dmosedale, :dmose)]

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.

Comment 2

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

(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..

Comment 3

[IU]

(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.

Comment 4

[Dan Mosedale (:dmosedale, :dmose)]

(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 [e-mail] (whom I've added to this bug), and then see if that problem goes away once bug 469878 is fixed.

Comment 5

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

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?

Comment 6

[Wayne Mery (:wsmwk)]

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

Comment 7

[Wayne Mery (:wsmwk)]

clicking "other actions" to seeing results (the menu) is 2 sec. Again, will probably be longer for smaller cpu

Comment 8

[IU]

Attachment: 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.

Comment 9

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

(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. :)

Comment 10

[Dan Mosedale (:dmosedale, :dmose)]

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.

Comment 11

[IU]

(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.

Comment 12

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: sample but with 75 recipients

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.

Comment 13

[Wayne Mery (:wsmwk)]

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"

Comment 14

[Dan Mosedale (:dmosedale, :dmose)]

(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.

Comment 15

[IU]

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.

Comment 16

[Dan Mosedale (:dmosedale, :dmose)]

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.

Comment 17

[David Ascher (:davida)]

Can someone test this with recent nighlies, and see if it still occurs?

Comment 18

[Dan Mosedale (:dmosedale, :dmose)]

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-.

Comment 19

[IU]

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:1.9.1.4pre) Gecko/20090916 Lightning/1.0pre ID:20090916031343

P3 933 MHz

Comment 20

[Wayne Mery (:wsmwk)]

I created a test messages in drafts with >300 recipients. Display in the message using 124 beta on Mac is instantaneous.