Closed
Bug 12896
Opened 25 years ago
Closed 15 years ago
Launch browser, mail/news DLLs loaded
Categories
(SeaMonkey :: General, defect)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: phil, Unassigned)
References
Details
(Keywords: perf, Whiteboard: [nav+perf])
Attachments
(1 file)
15.34 KB,
patch
|
Details | Diff | Splinter Review |
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.
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M11
Reporter | ||
Comment 1•25 years ago
|
||
Triage to M15
Comment 2•24 years ago
|
||
triaging since M15 is tonight. Not an M15 stoppper.
Target Milestone: M15 → M17
Comment 3•24 years ago
|
||
moving to future milestone. This is too complicated and risky to fix now.
Target Milestone: M17 → Future
Comment 4•24 years ago
|
||
Time to pull this in yet? I think we need mork for history (alec, bienvenu?), but the others can probably go.
Keywords: nsbeta1
Comment 5•24 years ago
|
||
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.
Comment 6•24 years ago
|
||
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.
Comment 7•23 years ago
|
||
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.
Comment 8•23 years ago
|
||
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.
Comment 9•23 years ago
|
||
How can this be both nsbeta1 AND nsbeta1- ? You're confusing the queries.
Comment 10•23 years ago
|
||
Dan: Apparently, putterman forgot to remove the nsbeta1 keyword when he minused it. Doing so now..
Keywords: nsbeta1
Comment 11•23 years ago
|
||
msgimap.dll 270,336 msgbsutl.dll 143,360 are still loaded on startup as of the latest win32 build.
Comment 12•23 years ago
|
||
*** Bug 46800 has been marked as a duplicate of this bug. ***
Comment 13•23 years ago
|
||
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?
Comment 14•23 years ago
|
||
waterson also suggested the idea of persisting these values ourselves instead of using localstore. That's under investigation.
Comment 15•23 years ago
|
||
marking nsbeta1+ and moving to 0.9.1 reassingning to bienvenu.
Comment 16•23 years ago
|
||
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
Comment 17•23 years ago
|
||
Comment 18•23 years ago
|
||
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.
Comment 19•23 years ago
|
||
sr=sspitzer
Comment 20•23 years ago
|
||
I checked in this patch - the remaining work is to use the elided bit for the expand collapse state of folders.
Status: NEW → ASSIGNED
Comment 21•23 years ago
|
||
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
Comment 22•23 years ago
|
||
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
Comment 23•23 years ago
|
||
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.
Comment 25•23 years ago
|
||
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
Updated•23 years ago
|
Whiteboard: [nsbeta1+][PDT+] → [nsbeta1+][PDT+][nav+perf]
Comment 26•23 years ago
|
||
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]
Comment 27•23 years ago
|
||
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
Comment 28•23 years ago
|
||
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
Comment 29•23 years ago
|
||
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
Updated•23 years ago
|
Whiteboard: [nsbeta1+][nav+perf] → [nav+perf]
Target Milestone: Future → mozilla1.0.1
Comment 30•22 years ago
|
||
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.
Updated•20 years ago
|
Product: MailNews → Core
Comment 32•19 years ago
|
||
(In reply to comment #31) > taking to check if fixed... Was it? Bitrot? Thanks.
Comment 33•19 years ago
|
||
this is now a seamonkey issue, if it's an issue at all...marking wontfix
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WONTFIX
Comment 34•19 years ago
|
||
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
Updated•19 years ago
|
Assignee: bienvenu → general
Status: REOPENED → NEW
QA Contact: stephend → general
Updated•16 years ago
|
Target Milestone: Future → ---
Comment 35•15 years ago
|
||
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: 19 years ago → 15 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•