Closed Bug 190409 Opened 23 years ago Closed 23 years ago

[FIXr]nsMIMEInfoImpl::GetApplicationDescription / GetDefaultDescription should be smarter

Categories

(Core Graveyard :: File Handling, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: bzbarsky, Assigned: bzbarsky)

Details

Attachments

(1 file, 1 obsolete file)

In particular, if the description is not set, they should return the leafname of the corresponding nsIFile...
Attached patch surprisingly few trivial uses... (obsolete) — Splinter Review
Attachment #112489 - Flags: superreview?(darin)
Attachment #112489 - Flags: review?(pkw)
Summary: nsMIMEInfoImpl::GetApplicationDescription / GetDefaultDescription should be smarter → [FIX]nsMIMEInfoImpl::GetApplicationDescription / GetDefaultDescription should be smarter
Comment on attachment 112489 [details] [diff] [review] surprisingly few trivial uses... >+ if (mPreferredAppDescription.IsEmpty()) { >+ // Don't want to cache this, just in case someone resets the app >+ // without changing the description.... >+ nsAutoString leafName; >+ mPreferredApplication->GetLeafName(leafName); >+ *aApplicationDescription = ToNewUnicode(leafName); Are we sure at this position that mPreferredApplication has been set? What would happen if we call GetApplicationDescription before SetPreferredApplicationHandler? >+ if (mDefaultAppDescription.IsEmpty()) { >+ // Don't want to cache this, just in case someone resets the app >+ // without changing the description.... >+ nsAutoString leafName; >+ mDefaultApplication->GetLeafName(leafName); >+ *aDefaultDescription = ToNewUnicode(leafName); Same as above but for mDefaultApplication. Would we benefit from doing an NS_ENSURE_ARG_POINTER in both of these functions to make sure that the description passed is non null? I know we don't currently do those checks, but it may be useful.
Oh, yes. We should be having a null-check there... I had them in an early revision of the patch, but they got lost. :( So the conditional should look like: >+ if (mPreferredAppDescription.IsEmpty() && mPreferredApplication) { No, we should not be doing NS_ENSURE_ARG_POINTER. At best, we could assert that the pointer is non-null. If it's null, someone has majorly violated XPCOM calling conventions.
Comment on attachment 112489 [details] [diff] [review] surprisingly few trivial uses... Ok don't worry about the assertion/NS_ENSURE_ARG_POINTER stuff. Add the null checks on mDefaultApplication/mPreferredApplication as shown in your last comment and r=pkw.
Attachment #112489 - Flags: review?(pkw) → review+
Comment on attachment 112489 [details] [diff] [review] surprisingly few trivial uses... sr=darin
Attachment #112489 - Flags: superreview?(darin) → superreview+
Summary: [FIX]nsMIMEInfoImpl::GetApplicationDescription / GetDefaultDescription should be smarter → [FIXr]nsMIMEInfoImpl::GetApplicationDescription / GetDefaultDescription should be smarter
Attachment #112489 - Attachment is obsolete: true
Checked in for 1.4a
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Marking verified per last comments.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: