MozillaZine

Mozilla Foundation, Apple, Macromedia, Opera and Sun to Improve Browser Plugins

Wednesday June 30th, 2004

The Mozilla Foundation is teaming up with Apple, Macromedia, Opera and Sun Microsystems to improve browser plugin technologies. The alliance will work on the extending the Netscape Plugin Application Program Interface to enhance interactivity and scriptability. Mozilla, Opera and Apple's Safari browser all use the Netscape plugin model, which debuted in Navigator 2.0. Meanwhile, Macromedia develops the popular Flash Player and Shockwave Player plugins, while Sun is behind the Java plugin. As well as Safari, Apple is also responsible for the QuickTime Player plugin. The only notable browser/plugin developer not in the new group is Microsoft, which dropped support for the Netscape plugin model in favour of ActiveX at Internet Explorer version 5.5. Slashdot has a story about the new plugin alliance.

Update: Adobe has been added to the members of the alliance listed in the Mozilla Foundation's press release.


#32 Gecko layout integration

by leafdigital

Friday July 2nd, 2004 5:09 AM

You are replying to this message

[Referring to a plugin standard for support of inline namespaced XHTML, in which a plugin handles elements from the DOM with a particular namespace.]

Well, although I admit I know essentially knowing about any Mozilla source code... I think the issue with frozen interfaces doesn't need to be a problem, especially as we aren't talking about Gecko alone but about all browsers; it wouldn't be Gecko's interfaces that were frozen, but the interfaces for these plugins. Gecko's constantly-changing interfaces would have to wrap around the standard, fixed plugin interface, as they do now for <object> tag-based plugins.

For a first cut I think it needn't be quite as hard as you suggest; the actual plugin model could be similarly limited to the current one (the plugin can only provide a single box of given pixel width/height), although probably with the extensions that IE already does (transparency, etc.).

All Gecko has to do is spot the namespaced elements in the tree, forward that part of the DOM and any changes to an instance of the appropriate plugin, and treat the plugin's content however it currently treats plugin content (more or less).

Basically this is almost equivalent to if you wrote Javascript or whatever that, on loading the page and before rendering, searched for namespaced elements that are handled by plugin; removed those elements from the file and saved them to a disk file; created a plugin object tag wiht the appropriate attributes.

Performance wouldn't be great but it shouldn't be particularly worse than plugins are now. Clearly this would not be an acceptable solution to all Gecko's layout problems - you certainly wouldn't want to implement a plugin that handled XHTML elements for instance! Also, it isn't really a great idea for 'core' technologies like SVG that might be used very frequently. But for the kind of things we use plugins for now? It should work ok.

--sam