36666 - progid prefix for XPCOM plugins should be changed

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect, P3)

Description

[Braden]

Persuant to this thread:

  <URL:news://news.mozilla.org/38F61824.615CF4C2%40netscape.com>

... it looks like this:
 
<URL:http://lxr.mozilla.org/mozilla/source/modules/plugin/public/nsIPlugin.h#52>

... ought to be changed. To what, I'm not exactly sure.
"mozilla.inline-plugin."?

Comment 1

[Braden]

Attachment: Patch to change plugin progid prefix to "mozilla.inline-plugin."

Comment 2

[av (gone)]

Eric, are there any marketing considerations here?

Comment 3

[Braden]

What bearing do Netscape marketing issues have on this bug? This is a Mozilla
bug.

That issue aside, I do have reservations about my previous recommendation for
changing this progID prefix.

Why is this progID prefix even necessary? Recent (exhaustive) discussion of
progIDs seems to conclude that they should be pretty opaque entities that need
only be compared as a whole. So it should never matter that all plugins start
with the same progID prefix.

I think this progID prefix should be scrapped altogether.

Comment 4

[Brendan Eich [:brendan]]

Adding XPCOM folks.

/be

Comment 5

[Mike]

M16 has been out for a while now, these bugs target milestones need to be 
updated.

Comment 6

[rusty.lynch]

Adding myself to cc

Comment 7

[Braden]

It looks like plugins are getting instantiated based on the parameterized
progID. This must change. The system should not fall apart just because someone
decides to have a different progID. More importantly, progIDs do not have a
sufficient guarantee of uniqueness in this role. (Two plugins serving the same
MIME type would have identical progIDs!)

I'll file a separate bug on this issue.

Comment 8

[Braden]

That issue is now under bug 44973. (I don't *think* it's a dependency or a
blocker for this one.)

Comment 9

[Braden]

Looks like rayw hit this as part of his progID -> contractID renaming. Marking
fixed.

Comment 10

[sean echevarria]

vrfy