Gecko:Moving Plugins To Content

From MozillaWiki
Revision as of 22:24, 2 January 2006 by Biesi (talk | contribs)
Jump to navigation Jump to search

bug 90268

https://bugzilla.mozilla.org/show_bug.cgi?id=88998 <-- seems to have a partial patch?

Christian Biesinger <cbiesinger@web.de> will probably work on this

Rationale

  • 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

Steps:

  • 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.