Closed
Bug 45029
Opened 24 years ago
Closed 23 years ago
remove Component manager contractID
Categories
(Core :: XPCOM, defect, P3)
Core
XPCOM
Tracking
()
RESOLVED
FIXED
mozilla1.0
People
(Reporter: braden, Assigned: dougt)
References
Details
(Keywords: arch)
While a progID for the component manager has been defined (<http://lxr.mozilla.org/seamonkey/source/xpcom/components/nsComponentManagerUtils.h#61>), it doesn't look like this ever gets registered. Thus attempts to get this service via its progID fail.
*** Bug 44979 has been marked as a duplicate of this bug. ***
Updated•24 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → M18
Comment 2•24 years ago
|
||
I am trying to figure out which XPCOM methods need to be exported. I assume that this should be the only method exported from XPCOM to get the component manager, right? If so, I nominate this for nsbeta3. If not, then it doesn't seem very important.
Keywords: nsbeta3
Updated•24 years ago
|
Whiteboard: [nsbeta3+]
Comment 3•24 years ago
|
||
Would whoever marked this nsbeta3+ please supply a simple use case why this particular progid needs to be registered in component manager?
Comment 4•24 years ago
|
||
Could you please explain why you want to get the component manager via its progid? I can think of a reason or two you might want to do this, but it seems that the component manager is readily available without being registered. Might the real solution not be just delete the definition? It is also not clear that this is a nsbeta3 bug.
Comment 6•24 years ago
|
||
Edward: Welcome to xpcom!
Status: ASSIGNED → NEW
QA Contact: leger → rayw
Target Milestone: M18 → mozilla1.0
Comment 7•24 years ago
|
||
Once again... attempting to reassign from Ray to Edward.
Assignee: rayw → kandrot
Comment 8•23 years ago
|
||
Since rayw's comments on 2000-08-31, there was no response as to why this is needed. I agree, and am therefore closing this bug.
Status: NEW → RESOLVED
Closed: 23 years ago
Keywords: nsbeta3
QA Contact: rayw → scc
Resolution: --- → INVALID
Whiteboard: [nsbeta3-]
Edward, rayw did not suggest that this bug was invalid. Rather, he suggested that a possible solution would be deleting the definition of the contractID.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Reporter | ||
Comment 10•23 years ago
|
||
To be clear, I don't see any problem with rayw's recommendation. But it is silly to have a contractID defined that never gets registered.
Assignee | ||
Comment 11•23 years ago
|
||
reassign all kandrot xpcom bug.
Assignee: kandrot → dougt
Status: REOPENED → NEW
Target Milestone: mozilla1.0 → ---
Assignee | ||
Updated•23 years ago
|
Target Milestone: --- → mozilla1.0
Assignee | ||
Updated•23 years ago
|
Keywords: mozilla1.0
Assignee | ||
Comment 12•23 years ago
|
||
I am marking this as wont fix. Currently, if you have the service manager, you should be able to qi it to the component manager.
Status: NEW → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WONTFIX
Reporter | ||
Comment 13•23 years ago
|
||
WONTFIX doesn't make sense here. If the verdict is, as you say, that the contractID should not exist, then the fix is simply to eliminate it. Keeping the contractID around when it's never registered is just confusing.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Summary: Component manager progID never registered → Component manager contractID never registered
Assignee | ||
Comment 14•23 years ago
|
||
agreed.
Summary: Component manager contractID never registered → remove Component manager contractID
Assignee | ||
Comment 15•23 years ago
|
||
This has been removed.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•