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.

See bug 64146 for the charset menu.

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.

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?

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

This patch just builds the menu on the first open.

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.

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.

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

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

still worthy?

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.