Closed Bug 11509 Opened 25 years ago Closed 25 years ago

[code] nsMsgAccountManager::prefService() needs to be more robust

Categories

(MailNews Core :: Backend, defect, P3)

x86
Windows NT
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: jband_mozilla, Assigned: alecf)

Details

[choosing a buzilla 'component' at random, 'assignedto' based on cvsblame]

nsMsgAccountManager::prefService() is part of what is called in just creating
the components with progids that begin with:

component://netscape/messengercompose/compose
component://netscape/messenger
component://netscape/rdf/datasource?name=msgaccountmanager
component://netscape/rdf/datasource?name=mailnewsfolders
component://netscape/rdf/datasource?name=msgnotifications
component://netscape/rdf/datasource?name=mailnewsmessages

(there may be others?)

It has the wonderful assert:

NS_ASSERTION(NS_SUCCEEDED(rv),
             "prefs service not available. I will crash soon!");

It delivers what it promises.

These components register themselves with the component manager and can be
instantiated from JS - with or without a prefs service handy.

Creating a component, doing a few QI calls and then Releasing it should never
crash the process. But here is does.

Please make this more robust.
Status: NEW → ASSIGNED
erg. I guess I was kind of expecting that prefs would be available, but I see
your point. I guess I better start using NS_WITH_SERVICE to load this service on
demand instead.
Target Milestone: M10
moving to M10
Summary: nsMsgAccountManager::prefService() needs to be more robust → [code] nsMsgAccountManager::prefService() needs to be more robust
I've made the following interface implementations much more robust with respect
to prefs:
nsMsgAccount
nsMsgAccountManager
nsMsgIdentity

I still have nsMsgIncomingServer to go.
(all to be checked in for M10)
Target Milestone: M10 → M11
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
ok, done. I even tried your cool enum script, and it works beautifully.
QA Contact: lchiang → ppandit
Changing QA contact to ppandit
Status: RESOLVED → VERIFIED
The usual way of making it more robust is the following:

if (m_prefs) return NS_OK;
return nsServiceManager::GetService(kPrefServiceCID,
                                      nsCOMTypeInfo<nsIPref>::GetIID(),
                                      (nsISupports**)&m_prefs,
                                      this);

Based on looking at the code, VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.