Currently messages which have hundred of recipients are slow to display. This is because we have to create a new email-address element for each address. Each of these newly created nodes goes into a long div for the to or the cc field, regardless of whether the user actually ends up toggling to the long address view when viewing the message. We could just store the addresses in some string arrays as part of the XBL widget. Then if the user actually shows the long header view, then we would spend the time constructing all of the email address widgets. This will help improve the "perceived" message display time for messages with long email addresses. Of course when you switch to the long view, then you'll pay the price and it will take some time.

.

This patch moves more functionality into the multi email address toggle XBL widget and out of the general JS in msgHdrViewOverlay.js. That part is going to help me down the road with 109929. With these changes, I am delaying construction of the long header view until the user clicks the twisty to go into the long header view for that widget. Of course if you are already in the long header view, then we still build it right away. I haven't done a new quantify run yet but this should help cut down a little bit on the amount of time we were spending in frame construction. Of course with the added complexity to the XBL widget, we'll lose some of the gain but we gain more than we lose =). As a side effect this also helps 64764 however it's still pretty slow 'cause of the time we spend in nsMsgParseMessageHeaders. So I'm leaving that bug open and untouched.

Comment on attachment 57661 [details] [diff] [review] patch sr=sspitzer. mscott said he'd change if (aAddressesNode.childNodes.length >= 1) to if (index) before checking in.

fix checked in.

We went from 12.20 seconds using the 13th Windows 98 build to 5.42 seconds using the 14th's build to read 5 of those message in a local mail folder... Verified FIXED. Nice work!