Closed Bug 99152 Opened 23 years ago Closed 23 years ago

Remove nsIShutdownListener

Categories

(Core :: XPCOM, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Future

People

(Reporter: dougt, Assigned: dougt)

References

Details

Attachments

(1 file)

Blocks: 98278
Target Milestone: --- → mozilla1.0
Is this bug 106466 a dependency or a duplicate? Anyway, it seems that shutdown listeners are now ignored, but there's still one implementation of nsIShutdownListener and the service is now being leaked. See bufferRoutines.h.
kinda vague. Lets leave this bug open to fix the string stuff.
Keywords: mozilla1.0
I fixed the string stuff ages ago...as far as I can tell there are no more implementations.
looking at lxr, all uses are gone. marking fixed.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Reopening. nsIShutdownListener is obsolete and it won't work if one tries to use it, so shouldn't we remove it from the tree? (If there are interfaces that are frozen that require the parameter, could they be changed to take |in nsISupports ignored|?)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
dbaron, no - nsIShutdownListener is still required for binary compatiblity with older interfaces.
So I could see leaving it as an opaque class name, but you could remove the contents of the class, at least, since it doesn't work anymore.
Can't you remove the definition of the class at: http://lxr.mozilla.org/seamonkey/source/xpcom/components/nsIServiceManagerObsolete.h#192 and make it *just* a forward declaration since nobody uses it and nobody should?
your right... at some point when this class is totally gone, we can remove it, but for now, we have to live with it declared. We don't know what clients require that this interface be defined.... It does not hurt anything. So I am pushing it out...
Keywords: mozilla1.0
Target Milestone: mozilla1.0 → Future
Where is a client that requires having it defined rather than just forward-declared?
Any client that relies on having it defined is broken already since shutdown observers don't work anymore.
dougt: just fix it stat, don't mislead ppl into implementing an interface that's never called. /be
dbaron - that is correct - they will never have there shutdown listener called. but they still can compile and in no way they will crash. brendan - what you do mean? it is obsolete, unsupported, and never will get called. we don't talk about it - it is not part of our API story for Mozilla 1.0. We left it because we wanted current clients of old service manager API continue to work for the most part. Its defination is event in a file named "nsIServiceManagerObsolete.h". It will never be exported into our XPCOM SDK. What more do you want?!
> dbaron - that is correct - they will never have there shutdown listener called. > but they still can compile and in no way they will crash. So who uses it? Everything pointed to by http://lxr.mozilla.org/seamonkey/search?string=nsIShutdownListener would compile with just a forward declaration since they're just signatures that allow null nsIShutdownListener pointers to be passed around.
dbaron, no one in *our* codebase.
dougt: I want what dbaron wants: get rid of the interface altogether and use a forwarded class declaration to introduce the name before it needs to be used in the backward-compatible places where it's used as a formal parameter type. /be
Attached patch removes nsIShutdownListener def (deleted) — Splinter Review
Although, i do not think that we need to do this, dbaron and brendan think it wise.
dbaron, brendan, hit the patch with r/sr's and I will check it in.
Comment on attachment 59417 [details] [diff] [review] removes nsIShutdownListener def wise or not, I'm willing to sr=alecf - good riddens!
Attachment #59417 - Flags: superreview+
r= anyone?
Comment on attachment 59417 [details] [diff] [review] removes nsIShutdownListener def r=dbaron
Attachment #59417 - Flags: review+
Checking in nsIServiceManagerObsolete.h; /cvsroot/mozilla/xpcom/components/nsIServiceManagerObsolete.h,v <-- nsIServiceManagerObsolete.h new revision: 3.3; previous revision: 3.2 done
dbaron, we will not know until they break and complain. :-/
making fixed.
Status: REOPENED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: