Open Bug 460605 Opened 12 years ago Updated 5 years ago

Message Reader: header pane right-click context menu popup takes too long for contacts in long list with lots of addresses

Categories

(Thunderbird :: Message Reader UI, defect, minor)

x86
Windows XP
defect
Not set
minor

Tracking

(Not tracked)

Thunderbird 3.0rc1

People

(Reporter: bugzilla2007, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Keywords: perf)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1b1pre) Gecko/20081006 Shredder/3.0a3

tb3a3: Reading an email with lots of adresses in to/cc/etc. fields, left- or right-click on one of them. It takes up to 3 seconds for the context menu to pop up (200 adresses in my list). With a short list, context menu pops up immediately.

Reproducible: Always

Steps to Reproduce:
1. read email with lots of recipients, expand the list (and try not to worry about Bug 223132)
2. click on one (display) adress within the list
3. 
Actual Results:  
context menu takes ages to appear (normal users will be confused and click again, which makes things worse, thus causing problems with normal usage of the menu)

Expected Results:  
context menu should appear immediately (no need for iterations at this point, I assume), as is the case with the collapsed list or short lists of recipients etc.

Additional problem: Expanding and collapsing the list also takes too long and should be read in advance as soon as the message is displayed.
This might block, it's a little hard to tell without more data and measurements.  If this were only true for message with 200 recipients, we wouldn't block on it, because those messages are pretty rare.  It would be interesting to know how bad it is for messages with, say, 10 or 15 recipients on a computer with "average" speed and memory.
Component: General → Message Reader UI
Flags: blocking-thunderbird3?
Keywords: perf, qawanted
QA Contact: general → message-reader
Whiteboard: [needs more data]
Wouldn't block based on the data we have now; so minusing.  Assigning to Gary for some testing love.
Assignee: nobody → nth10sd
Flags: blocking-thunderbird3? → blocking-thunderbird3-
Target Milestone: --- → Thunderbird 3.0rc1
This might be related to bug 479989.

Using the testcases in the attachments of bug 479989, on a C2D MBP 4Gb ram, I get no slowdown with the context menu when I had not previously hovered over "hide details" and "other actions". However, once I hovered over them and immediately went to click any email address, the context menu takes 1-2 sec of lag to show the context menu (the 1,398 recipient testcase did this for me, with 75 it's less noticeable for me but again probably due to my fast computer.)

Wayne, IU, would you guys like to do a quick "eyeball" of the attachments there on TB and see if the situation described in comment #0 of this bug applies?
Version: unspecified → Trunk
my test results are iffy (not terribly conclusive) but may be helpful, but what I see with 75 recipient testcase of bug 479989:
* barely perceptible delay, using default theme
* no perceptible delay using littlebird theme - littlebird does not offer scroll bar of headers
Ludo, would you like to have a quick look at this as well?
Deassigning myself, I have already tested as per comment #3, and don't have slow machines to test on.
Assignee: nth10sd → nobody
Ludo, is this something you can have a look at soonish?
(In reply to comment #7)
> Ludo, is this something you can have a look at soonish?

I had a look a while back an nothing to add to what Gary and Wayne stated. I changed one of the test case to have all the signatures different just in case something got cached but did not notice any difference - as Gary said machine is speedy.

Thomas (bug reporter), do you still have the issue with the nightlies ? Are you running any extension , using a special theme ? If this is still the case could you share such an email with me privately ?
I can still see this bug very clearly with the current nightly,
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090408 Shredder/3.0b3pre.

Ludo, you have a mail.

My TB: All addons disabled except for MailTweak 0.16 and German Dictionary. 
Header UI tweaks and more 1.01 (from  Bug 466025 - explore message header tweaks and variants for tb3 [and polish]) is still in extensions folder but also disabled according to addon-manager.

My machine is Celeron 2.6 GHZ, 704 MB RAM, 40 GB harddrive. 1 GB free space on C:, but much defragmentation and generally slow (running XP for several years without reinstall).

Important update on initial summary:
The delay in context menu popup occurs
- only after you have expanded the header field using "more" button so that you see all contacts of that header (cf. Gary's similar observation in comment #3)
- only when you *right-click* on the contact's caption in the mail header pane (whereas for left-click: no delay any more!)
- only for the first time you click on each contact (whereas for second click in a row on same contact: no delay any more). So you must click on another contact each time to see the effect
- much more striking for emails with lots of contacts (200), where the delay is still 2-3 seconds as initially reported; yet even for 20 contacts, there is a delay of 1/2 to 1 second when you right-click in comparison to the immediate-response menu pop-up for left click.

Since left-click works fine, this bug is not really about machine speed, but there must be some difference in the underlying code that does unnecessary loops for each of the contacts when right-clicking on a single contact, whereas for left-click, execution of such loops is either quicker or there's no loop going on at all. And I assume clicking on a single address SHOULD NOT cause loops of any kind which go through 200 addresses before opening your context menu for single address no. 50.

Other problems in this corner:
- after clicking "more"-button, delay of about 2-4 secs before all contacts are shown (should be pre-fetched! and/or check your loops...)
- right-click -> context menu pops up -> don't close -> see that you clicked the wrong address and /right-away/ right-click on a different contact -> nothing (2 clicks for openening the next context menu doesn't feel right, but I think I posted that already? Same for left-click.)
Summary: Message Reader: header pane context menu popup takes too long for contacts in long list with lots of addresses → Message Reader: header pane right-click context menu popup takes too long for contacts in long list with lots of addresses
So I do see a slight delay difference between right clicking and left clicking. I will try with MailTweak and see if it make a difference. Thanks for the email, thanks for all the precision. Testing on my mac. 

On Windows(In a VM) the delay is slightly longer - and is really noticeable - like something probably as long as 1/4 to 1/2 a second. 

Dan what else would you like to know ?

The other issues are probably worth filling other bugs.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [needs more data]
removing qawanted for now.
Keywords: qawanted
The additional comments have been very helpful; thanks to both of you!  I believe this is very much wanted for Thunderbird 3, but if it were the last bug standing, we wouldn't block on it.  The cause is almost certainly that when the addresslist is expanded with lots of addresses, there are lots and lots of DOM nodes, and DOM performance is a known weakness of Gecko.  

The next step is probably to do some profiling using the JS hooks for DTrace (are there separate Shark hooks that are also worth looking at?) in order to better understand the nature of the slowness and look for low-hanging fruit to fix.
Flags: wanted-thunderbird3+
not suggesting they fix each other, but likely this and bug 487688 correlate in some way, so setting dependency.

for ~300 addresses my r-click delay of an address is 3-4 sec. that, and a second or two are somewhat minor usability issue, so sev=minor given the l-click workaround works fine.

bug 487688, clicking "more", is ~26 sec
Severity: normal → minor
Depends on: 487688
Blocks: 813496
I routinely get emails with many addresses. This is a large nuisance.

It has been 5 years this bug was identified, can we upgraded and have someone please work on it?
(In reply to Bob from comment #14)
> I routinely get emails with many addresses. This is a large nuisance.
> 
> It has been 5 years this bug was identified, can we upgraded and have
> someone please work on it?

No one stops you from trying.

See also https://bugzilla.mozilla.org/page.cgi?id=etiquette.html and especially its §1.2
See Also: → 693295
I get this alert "The message could not be filtered to folder X because writing to folder failed. Verify that you have enough disk space, and that you have write privileges to the file system, then try again."
There is space and I have privileges. I am on Windows 7, and I reapplied the permissions.
Then immediately Thunderbird crashes!
When I start it again, the same thing happens over and over upon trying to download messages.
See Also: → 1177040
You need to log in before you can comment on or make changes to this bug.