Closed Bug 12896 Opened 20 years ago Closed 11 years ago

Launch browser, mail/news DLLs loaded

Categories

(SeaMonkey :: General, defect)

x86
Windows NT
defect
Not set

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: phil, Unassigned)

References

Details

(Keywords: perf, Whiteboard: [nav+perf])

Attachments

(1 file)

When I launch apprunner to the browser, I see the NT loader rebasing
msgbase.dll, msgbsutl.dll and mork.dll. Doesn't seem like these mail/news
components should be loaded when the browser launches.
Status: NEW → ASSIGNED
Target Milestone: M11
Triage to M15
triaging since M15 is tonight. Not an M15 stoppper.
Target Milestone: M15 → M17
moving to future milestone.  This is too complicated and risky to fix now.
Target Milestone: M17 → Future
Time to pull this in yet?  I think we need mork for history (alec, bienvenu?), 
but the others can probably go.
Keywords: nsbeta1
Mork is needed for history, and is not part of mail/news proper (it's in the
mozilla/db directory, not mozilla/mailnews.

But the reason mail/news dlls get loaded is because your localstore.rdf mentions
mail/news URI's, which causes our dlls to get loaded. That's what Scott is
saying is too complicated to fix anytime soon, having mail/news URI's in 
localstore.rdf NOT cause mail/news dlls to get loaded.
Keywords: nsbeta1
yes, fixing this problem the 'right' way is rediculously hard - there's a bug
assigned to sspitzer about using RDF delegates for mail objects, that's the
'right' way to fix this bug.

The other way to 'fix' this bug is to break localstore.rdf into a per-chrome
file, such that localstore-messenger.rdf doesn't get loaded until a
chrome://messenger url is loaded. CC'ing waterson and hyatt to see what they
think, since it's a XUL issue and a bloat issue.
nominating for the potentially easier fix (splitting the mail part of 
localstore into a separate file).  We're slow enough at startup (most of the 
time spent loading libraries) without adding extra libraries we could delay.
Blocks: 7251
Keywords: nsbeta1, nsCatFood, perf
Target Milestone: Future → ---
Blocks: 46800
marking nsbeta1- but nscatfood+.  I've been told by waterson that the fix that 
dveditz is proposing is not easy.  If you can find out a way to do this that's 
easy then we can look into this.
How can this be both nsbeta1 AND nsbeta1- ?  You're confusing the queries.
Dan: Apparently, putterman forgot to remove the nsbeta1 keyword when he minused
it. Doing so now..
Keywords: nsbeta1
msgimap.dll    270,336
msgbsutl.dll   143,360                                                          
                          
are still loaded on startup as of the latest win32 build.                       
 
Blocks: 71781
No longer blocks: 7251
*** Bug 46800 has been marked as a duplicate of this bug. ***
Yes, I forgot to remove the nsbeta1.  I'm sorry I confused the queries that I'm
pretty sure I was the only one looking at.

I know two ways to solve this:

1.  Rewrite mailnews folder RDF code.  That's not going to happen at the moment.

2.  Make it so that localstore.rdf can be split into a mailstore.rdf.  The last
I talked to waterson, I was told this would be really hard.  Chris any comments
on what the risk would be in doing this?
waterson also suggested the idea of persisting these values ourselves instead of
using localstore. That's under investigation.
marking nsbeta1+ and moving to 0.9.1  reassingning to bienvenu.
Assignee: mscott → bienvenu
Status: ASSIGNED → NEW
Keywords: nsbeta1-nsbeta1
Priority: P3 → P1
Whiteboard: [nsbeta1+]
Target Milestone: --- → mozilla0.9.1
moving to 0.9.2 but if you're able to get to this this before, then go for it.
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Can I get an r/sr= for this patch? The remaining work is to persist the elided
flag for folders, which I'll attack later.
I checked in this patch - the remaining work is to use the elided bit for the
expand collapse state of folders. 
Status: NEW → ASSIGNED
should we open another bug to clear out the old resources from localstore.rdf?
Otherwise people who upgraded from N6.0x will still get the dlls loaded
Is that even technically possible, Alec, other than writing special code to
grope through the file? We can't assume that the current folders are the set of
folders the user might have ever had stored in localstore.rdf
argh.. I just looked at localstore, I thought they were all in a sequence off of
a well-known resource, but actually all you have to do is call GetAllResources
on the localstore datasource, and for each resource:
   if it has an imap:, mailbox: or news: schema, 
     remove all arcs coming out of it.

adding PDT+
Whiteboard: [nsbeta1+] → [nsbeta1+][PDT+]
moving this to future.  It looks like the rest of this bug will get fixed with
the Folder Pane rewrite.  Let's keep this around to make sure.
Target Milestone: mozilla0.9.2 → Future
Whiteboard: [nsbeta1+][PDT+] → [nsbeta1+][PDT+][nav+perf]
Since the rest of this bug is assigned to future, I am going to remove the PDT+.
Whiteboard: [nsbeta1+][PDT+][nav+perf] → [nsbeta1+][nav+perf]
Seth, now that the folder outliner has landed is this fixed? putterman said he
thought this was going to just start working once the folder pane branch landed
but I'm not so sure. We still use RDF in the folder pane. We are just using the
bridge to talk to the outliner widget. So in theory the same RDF problems should
still be there. 
Assignee: bienvenu → sspitzer
Status: ASSIGNED → NEW
in theory, this should be fixed - we still use rdf, but the tree is no longer
persisting folder uris for things like expand/collapse state (because we're not
using the tree widget), so we shouldn't have folder uris written to localstore.rdf
Blocks: 104166
Blocks: 63759
If I am a N6 or N6.1 user, aren't we going to load the mail dlls anyway, even if
we aren't using them, because I have the resources in my localstore.rdf? 

I'd like to suggest that we have some pref like "mailnews.localstore.clean" that
defaults false... when mail starts (or a dll is loaded) we could check that
pref, and if it's false, then we walk localstore.rdf and remove all mail
resources...
QA Contact: lchiang → stephend
Whiteboard: [nsbeta1+][nav+perf] → [nav+perf]
Target Milestone: Future → mozilla1.0.1
I think this is related to bug 106087. Maybe not exactly a dupe because it is
about another dll, but perhaps we could merge the 2 bugs or something like that
or at least work combine the efforts made in these 2 bugs.
taking to check if fixed...
Assignee: sspitzer → bienvenu
Product: MailNews → Core
(In reply to comment #31)
> taking to check if fixed...

Was it? Bitrot? Thanks.
this is now a seamonkey issue, if it's an issue at all...marking wontfix
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
If this is for seamonkey, then it should be set to Moz App Suite.
Status: RESOLVED → REOPENED
Component: MailNews: Backend → General
Priority: P1 → --
Product: Core → Mozilla Application Suite
Resolution: WONTFIX → ---
Target Milestone: mozilla1.0.1 → Future
Assignee: bienvenu → general
Status: REOPENED → NEW
QA Contact: stephend → general
Target Milestone: Future → ---
Mail/news is an integral piece of SeaMonkey, by default we're even checking for new mails on browser startup now. WONTFIX.
Status: NEW → RESOLVED
Closed: 14 years ago11 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.