Gecko:Moving Plugins To Content

From MozillaWiki
Jump to: navigation, search

This work was completed in bug 90268 for Firefox 13. Thanks to Josh Aas for his excellent work there fixing all hosts of issues and driving this to completion! Note: the below content is from 2006 and may be out of date; see the bug for actual implementation details.

See also for some docs on the current plugin architecture.


  • Plugins should not get reloaded by reframes, e.g. when the display: of a node changes.
  • Plugins that have no frames should still be instantiated

The Plan


  • Move nsPluginInstanceOwner to its own file
    • Make it implement a new interface nsPIPluginInstanceOwner which has all the methods needed for objectframe<->instanceowner communication
    • Extend nsIObjectFrame with methods the instance owner needs to call (if any)
    • Make the instance owner own a content node rather than a frame (probably)
    • Provide method NS_NewPluginInstanceOwner or something. also takes care of Init
  • Move that file to content (or, directly add it in content)
  • ...
  • Create the owner on the content node. Provide a method on nsIObjectFrame to tell it that the plugin instance owner changed. provide a method to get the current instance owner. (Similar to how nsIImageLoadingContent works)
  • I considered making an nsMacPluginInstanceOwner, subclass of nsPluginInstanceOwner. All those #ifdef XP_MAC code would move there. Thoughts?

Plugins without frames

What should happen with plugins that have no frame?

Possibilities, that I can think of right now:

Other questions

  • Who owns the widget? The instance owner, or the frame?
    • Note that some functions (some listeners) require a widget.