Closed Bug 11509 Opened 27 years ago Closed 26 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: 26 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.