remove Component manager contractID

RESOLVED FIXED in mozilla1.0

Status

()

Core
XPCOM
P3
normal
RESOLVED FIXED
18 years ago
16 years ago

People

(Reporter: Braden, Assigned: dougt)

Tracking

({arch})

Trunk
mozilla1.0
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

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

Comment 1

18 years ago
*** Bug 44979 has been marked as a duplicate of this bug. ***

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → M18

Updated

18 years ago
Depends on: 46768

Comment 2

18 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

18 years ago
Whiteboard: [nsbeta3+]

Comment 3

18 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

18 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 5

17 years ago
nsbeta3-
Whiteboard: [nsbeta3+] → [nsbeta3-]

Comment 6

17 years ago
Edward: Welcome to xpcom!
Status: ASSIGNED → NEW
QA Contact: leger → rayw
Target Milestone: M18 → mozilla1.0

Comment 7

17 years ago
Once again... attempting to reassign from Ray to Edward.
Assignee: rayw → kandrot
(Reporter)

Updated

17 years ago
Keywords: arch

Comment 8

17 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
Last Resolved: 17 years ago
Keywords: nsbeta3
QA Contact: rayw → scc
Resolution: --- → INVALID
Whiteboard: [nsbeta3-]
(Reporter)

Comment 9

17 years ago
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

17 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

17 years ago
reassign all kandrot xpcom bug.
Assignee: kandrot → dougt
Status: REOPENED → NEW
Target Milestone: mozilla1.0 → ---
(Assignee)

Updated

16 years ago
Target Milestone: --- → mozilla1.0
(Assignee)

Updated

16 years ago
Keywords: mozilla1.0
(Assignee)

Comment 12

16 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
Last Resolved: 17 years ago16 years ago
Resolution: --- → WONTFIX
(Reporter)

Comment 13

16 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

16 years ago
agreed.
Summary: Component manager contractID never registered → remove Component manager contractID
(Assignee)

Comment 15

16 years ago
This has been removed.
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.