68375 - lazily root the file,copy,fcc2,charset,tasks,etc menus in the datasources

Status: NEW

(MailNews Core :: Backend, defect)

Description

[(not reading, please use [e-mail] instead)]

we should build up our generated file and copy menus *really* lazily.

We have several such menus in the three pane, stand alone window, and 
one in compose.

Right now, we set the datasources for those menus on loading of the xul 
(or they are hard coded in the xul, in the compose case), instead of 
when the user clicks on the menu item or toolbar button.

I'm guessing it would speed up launch time for our windows, but would 
slow down the response time the first time you click.

The one that is bugging me the most is the Fcc menu item in compose.  
I'm glad is there, but I've never use it.  Why should I pay for it every 
time I create a message?

when we get to this, I'll probably need racham, ducarroz and some from i18n to
pitch in.

Comment 1

[Jesse Ruderman]

See bug 64146 for the charset menu.

Comment 2

[(not reading, please use [e-mail] instead)]

I think gayatrib fixed some of these problems in our search xul.

bhuvan was recently fixing the file/copy/pickers, he'd be a good person to fix.

re-assign to him.

Comment 3

[[e-mail]]

I've got some JS that does this for the move/copy menus; does anyone have a 
complete list or should I just search the XUL for datasources attributes?

Comment 4

[[e-mail]]

Attachment: Proposed patch A

This patch rebuilds the menu every time it is opened.
Without it the menu didn't appear to update after rename/create folder
operations.

Comment 5

[[e-mail]]

Attachment: Proposed patch B

This patch just builds the menu on the first open.

Comment 6

[(not reading, please use [e-mail] instead)]

cavin has been testing the patch.

he writes:  "ok, without the fix nsXULContentBuilder::Rebuild() gets called 8 
times. with the fix it's 0 (and gets called when we try to use the menus 
(move/copy msg, file msg)..."

cavin, was that with neils first patch, or the second one?

we definitely want this for perf and footprint.

one thing about setting a database manually, we have to remove it manually too.

Comment 7

[[e-mail]]

Seth Spitzer wrote:

> one thing about setting a database manually, we have to remove it manually too.

You didn't remove it manually before...

Proposed Patch A can be modified to manually remove the database, but B can not.

Comment 8

[Cavin Song]

> cavin, was that with neils first patch, or the second one?
>
It's the second one (ie=57005) I tried.

Comment 9

[Cavin Song]

From my tests it seems to only save about 30-40 ms.

Comment 10

[Wayne Mery (:wsmwk)]

still worthy?

Comment 11

[Serge Gautherie (:sgautherie)]

perf/footprint should be reevaluated after (at least) bug 68174 <messengercompose.xul> part lands...
Unless it would be obvious that we still do want the lazy version.