Closed Bug 597293 Opened 14 years ago Closed 12 years ago

Remove nsIFactory.LockFactory - no callers

Categories

(Core :: XPCOM, defect)

defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: WeirdAl, Unassigned)

References

()

Details

(Keywords: arch, Whiteboard: postpone)

Attachments

(1 file)

I see no evidence that any Mozilla code calls LockFactory.  It looks like dead code, in 24 different files on comm-central (20 different files on mozilla-central).
Must not do this until after branch, for binary-compat purposes (nsIFactory is compatible with some MS interface of old, too!).
Can this be done now? The number of places where it is defined has increased now.
Can I take it? Can the definitions just be removed?
OS: Windows 7 → All
Hardware: x86 → All
Version: unspecified → Trunk
Attached patch patchSplinter Review
Here's the m-c patch.  I don't know what to do about the c-c fallout.
Attachment #620702 - Flags: superreview?(benjamin)
Attachment #620702 - Flags: review?(benjamin)
Comment on attachment 620702 [details] [diff] [review]
patch

>diff --git a/xpcom/components/nsIFactory.idl b/xpcom/components/nsIFactory.idl
>index 349cee6..947d442 100644
>--- a/xpcom/components/nsIFactory.idl
>+++ b/xpcom/components/nsIFactory.idl
>@@ -57,21 +57,9 @@ interface nsIFactory :  nsISupports {
>     *                 being requested was successfully returned in result.
>     *         NS_NOINTERFACE - Interface not accessible.
>     *         NS_ERROR_NO_AGGREGATION - if an 'outer' object is supplied, but the
>     *                                   component is not aggregatable.
>     *         NS_ERROR* - Method failure.
>     */
>     void createInstance(in nsISupports aOuter, in nsIIDRef iid,
>                       [retval, iid_is(iid)] out nsQIResult result);
>-
>-   /**
>-    * LockFactory provides the client a way to keep the component
>-    * in memory until it is finished with it. The client can call
>-    * LockFactory(PR_TRUE) to lock the factory and LockFactory(PR_FALSE)
>-    * to release the factory.	 
>-    *
>-    * @param lock - Must be PR_TRUE or PR_FALSE
>-    * @return NS_OK - If the lock operation was successful.
>-    *         NS_ERROR* - Method failure.
>-    */
>-    void lockFactory(in boolean lock);
> };

Drive-by comment:  you still need to rev the UUID here.

I believe there's a script for finding what other UUID's need revving, but I don't know where that lives.
(In reply to Alex Vincent [:WeirdAl] from comment #4)
> Drive-by comment:  you still need to rev the UUID here.
> 
> I believe there's a script for finding what other UUID's need revving, but I
> don't know where that lives.

Thanks, will do.  I don't think I need to rev any other UUIDs, since no other interface derives from nsIFactory...unless I have to change UUIDs of interfaces that return or accept nsIFactorys?  Ugh.
I don't think that this change is worth the churn: there are still binary components out there in relatively prominent extensions, and this change might mean more than a recompile (and we have some evidence that they are often being tricky about trying to load the same DLL into multiple versions of Firefox).

So I'd like to postpone this fix... indefinitely, or at least until something equally breaking comes along that we are going to take.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INCOMPLETE
Whiteboard: [good first bug] → postpone
Attachment #620702 - Flags: superreview?(benjamin)
Attachment #620702 - Flags: review?(benjamin)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: