Gecko:Moving Plugins To Content
From MozillaWiki
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 http://developer.mozilla.org/en/docs/Plugin_Architecture for some docs on the current plugin architecture.
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:
- They have a widget that's clipped to an empty rect
- This has issues when the document doesn't have a presentation (as opposed to just the node having no frame)
- They have no widget. NPP_SetWindow is called with something that indicates no window (NULL window arg, or null aWindow->window, whatever)
Other questions
- Who owns the widget? The instance owner, or the frame?
- Note that some functions (some listeners) require a widget.
