Closed Bug 637253 Opened 13 years ago Closed 13 years ago

decomtamination: remove nsIPlugin and nsIPluginInstance

Categories

(Core Graveyard :: Plug-ins, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: jaas, Assigned: jaas)

References

(Blocks 1 open bug)

Details

Attachments

(3 files, 9 obsolete files)

We don't need nsIPlugin or nsIPluginInstance. We should get rid of them.
Attached patch fix v1.0 (obsolete) — Splinter Review
Compiles and works for 32-bit Mac OS X. Probably doesn't even compile on other platforms yet.
This would break non-libxul builds. We should stop making the plugin code its own library and just build it with dom/plugins. I'll file a new bug and make this depend on that.
We are going to intentionally remove the --disable-libxul build configuration post-4.0, FWIW. Fewer configurations to support + more opportunities for deCOM like this.
Attached patch fix v1.1 (obsolete) — Splinter Review
Update to current trunk.
Attachment #515571 - Attachment is obsolete: true
Attachment #519122 - Flags: review?(benjamin)
Attached patch fix v1.2 (obsolete) — Splinter Review
Linux build fixes.
Attachment #519122 - Attachment is obsolete: true
Attachment #519122 - Flags: review?(benjamin)
Attachment #519146 - Flags: review?(benjamin)
Attachment #519146 - Flags: review?(benjamin)
Attachment #519146 - Attachment is obsolete: true
Attached patch remove nsIPlugin, v1.0 (obsolete) — Splinter Review
Attachment #527721 - Flags: review?(benjamin)
Attached patch remove nsIPlugin, v1.1 (obsolete) — Splinter Review
Attachment #527721 - Attachment is obsolete: true
Attachment #527721 - Flags: review?(benjamin)
Attachment #529114 - Flags: review?(benjamin)
Attached patch remove nsIPlugin, v1.2 (obsolete) — Splinter Review
A better way to deal with nsPluginHost::GetPlugin.
Attachment #529114 - Attachment is obsolete: true
Attachment #529114 - Flags: review?(benjamin)
Attachment #531348 - Flags: review?(benjamin)
Why still inherit from nsISupports?
(In reply to comment #9)
> Why still inherit from nsISupports?

I'm planning to stop doing that but I want to limit the size/depth of each patch. I'll get that in another set of patches soon.
Attachment #531348 - Flags: review?(benjamin) → review+
Update to current trunk.
Attachment #531348 - Attachment is obsolete: true
pushed nsIPlugin interface removal to mozilla-central

http://hg.mozilla.org/mozilla-central/rev/6eb2b03b6fd5
Attached patch remove nsIPluginInstance, v1.0 (obsolete) — Splinter Review
Attached patch remove nsIPluginInstance, v1.1 (obsolete) — Splinter Review
Linux compile fixes.
Attachment #532028 - Attachment is obsolete: true
Attached patch remove nsIPluginInstance, v1.2 (obsolete) — Splinter Review
Windows build fixes.
Attachment #532067 - Attachment is obsolete: true
Attachment #532105 - Flags: review?(benjamin)
Attachment #532105 - Flags: review?(benjamin) → review+
QT build fixes.
Attachment #532105 - Attachment is obsolete: true
pushed nsIPluginInstance interface removal to mozilla-central

http://hg.mozilla.org/mozilla-central/rev/5ffdf4967dec
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Depends on: 657868
Setting this as Verified as of #comment 17
Status: RESOLVED → VERIFIED
Since nsNPAPIPluginInstance isn't an XPCOM component anymore there is no way for a plugin to get the JSContext associated with an instance. This patch try to remedy it. I'm not sure this is the right way to do it.
Thanks for your contribution, but please file a new bug for any further patches, this bug is closed out and done.
OK. filed: https://bugzilla.mozilla.org/show_bug.cgi?id=670629
Thanks for your help.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: