Remove nsIFactory.LockFactory - no callers

RESOLVED INCOMPLETE

Status

()

Core
XPCOM
RESOLVED INCOMPLETE
7 years ago
6 years ago

People

(Reporter: WeirdAl, Unassigned)

Tracking

({arch})

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: postpone, URL)

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
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).

Comment 1

7 years ago
Must not do this until after branch, for binary-compat purposes (nsIFactory is compatible with some MS interface of old, too!).
Blocks: 457262

Comment 2

6 years ago
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
Created attachment 620702 [details] [diff] [review]
patch

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)
(Reporter)

Comment 4

6 years ago
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.

Comment 6

6 years ago
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
Last Resolved: 6 years ago
Resolution: --- → INCOMPLETE
Whiteboard: [good first bug] → postpone

Updated

6 years ago
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.