Closed
Bug 190409
Opened 23 years ago
Closed 23 years ago
[FIXr]nsMIMEInfoImpl::GetApplicationDescription / GetDefaultDescription should be smarter
Categories
(Core Graveyard :: File Handling, defect)
Core Graveyard
File Handling
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: bzbarsky, Assigned: bzbarsky)
Details
Attachments
(1 file, 1 obsolete file)
|
5.35 KB,
patch
|
Details | Diff | Splinter Review |
In particular, if the description is not set, they should return the leafname of
the corresponding nsIFile...
| Assignee | ||
Comment 1•23 years ago
|
||
| Assignee | ||
Updated•23 years ago
|
Attachment #112489 -
Flags: superreview?(darin)
Attachment #112489 -
Flags: review?(pkw)
| Assignee | ||
Updated•23 years ago
|
Summary: nsMIMEInfoImpl::GetApplicationDescription / GetDefaultDescription should be smarter → [FIX]nsMIMEInfoImpl::GetApplicationDescription / GetDefaultDescription should be smarter
Comment 2•23 years ago
|
||
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.
| Assignee | ||
Comment 3•23 years ago
|
||
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 4•23 years ago
|
||
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 5•23 years ago
|
||
Comment on attachment 112489 [details] [diff] [review]
surprisingly few trivial uses...
sr=darin
Attachment #112489 -
Flags: superreview?(darin) → superreview+
| Assignee | ||
Updated•23 years ago
|
Summary: [FIX]nsMIMEInfoImpl::GetApplicationDescription / GetDefaultDescription should be smarter → [FIXr]nsMIMEInfoImpl::GetApplicationDescription / GetDefaultDescription should be smarter
| Assignee | ||
Comment 6•23 years ago
|
||
Attachment #112489 -
Attachment is obsolete: true
| Assignee | ||
Comment 7•23 years ago
|
||
Checked in for 1.4a
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Updated•9 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•