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

#### #1 And of course Micro$soft will not join you by darnell Wednesday June 30th, 2004 9:41 AM The company bigger than all the rest combined does not need to! With over 90% of the browser maket what would you expect? Given they now have the majority they are gonna tell you to buy windows use IE and love it ;o) . #### #2 Re: And of course Micro$soft will not join you

by anand

Wednesday June 30th, 2004 10:02 AM

It is a little odd to see Adobe missing as well. The PDF reader plugin is probably one of the most commonly used plugins and its performance on the latest versions of Firefox have been less than perfect, so I'd think they'd jump on the chance to improve their product.

#### #14 Re: Re: And of course Micro$soft will not join you by scottj Wednesday June 30th, 2004 4:14 PM I guess Adobe thought it odd, too. Nice to see they have now joined the pack. #### #22 Re: And of course Micro$soft will not join you

by voracity

Thursday July 1st, 2004 12:25 AM

It doesn't matter, so long as it's possible to create an activex plugin that supports the new nsapi plugins. I have no idea if that's possible, but since the reverse was done some time ago, I assume it is.

#### #3 They're there...

by screed

Wednesday June 30th, 2004 10:59 AM

"The Mozilla Foundation, in partnership with Adobe, Apple, Macromedia, Opera and Sun Microsystems..."

#### #4 Plug-in scriptability

by theuiguy

Wednesday June 30th, 2004 11:24 AM

Aren't plug-ins already scriptable? I seem to remember a big deal about the flash plug-in being scriptable in a Mozilla release a while back. Java applets are scriptable, aren't they?

Is this just a new way for plug-in vendors to create scriptable plug-ins that will work in a broad range of browsers? From the standpoint of a web developer would much change?

#### #7 Re: Plug-in scriptability

by petebull

Wednesday June 30th, 2004 11:55 AM

What I hope that will be accomplished is that the browser can stop flash animations when I hit the stop button after the page has loaded.

One thing I love Konqueror for is "Stop Animations" in the context menu. I simulated this with the "Nuke Anything" extension, but I'm sure a lot of people will like that.

#### #8 Re: Re: Plug-in scriptability

by Yacoubean

Wednesday June 30th, 2004 12:20 PM

You made Nuke Anything? That's one of my favorite extensions! I hate it when I'm reading an article (most of my web surfing) and there's an annoying flash or animated gif on the page. The stop button idea you mentioned would fix some of the problem, but not all. I also use Nuke Anything to remove offensive images I don't want staring at me. For example, the other day there was a photo of Michael Moore inline in an article I was reading. No matter what your politics, that man is UGLY! I Nuked that image. :)

#### #30 Re: Re: Re: Plug-in scriptability

by petebull

Thursday July 1st, 2004 3:31 PM

Nah, I merely used Nuke Anything.

Ted wrote it: http://ted.mielczarek.org/code/mozilla/

I did, however, modify "Nuke Image" to function like "Nuke Anything" when Ted changed that N.I. could only affect images.

And Flash Block is a nice extension too. I might have dumped that when I was testing more nightlies. Will be an excellent candidate for reinclusion to my installed extensions and a nice test for the extension managers updating functionality.

#### #17 Re: Re: Plug-in scriptability

by itsayellow

Wednesday June 30th, 2004 8:48 PM

You should try the flashblock extension: http://flashblock.mozdev.org/ It shows a discrete placeholder which you can click on if you actually want to start the flash animation. Also, the project seems to be looking for knowledgeable developer help...

#### #5 What about Firefox?

by Yacoubean

Wednesday June 30th, 2004 11:43 AM

This news seems kind of odd to me considering all the work put into the firefox extension engine lately. I realize that a Moz/Firefox extension is a different animal than a plugin, but does it need to be? Why can't Flash/Acrobat/Java/etc. be xpi's? I know that I'd much prefer to install a plugin as an xpi (even though I'd need to restart my browser). Its not a big deal to download and run an executable, but its not nearly as convenient as xpi's.

#### #6 Re: What about Firefox?

by darinwf

Wednesday June 30th, 2004 11:48 AM

Keep in mind that XPIs are a Mozilla specific technology. NPAPI is cross-browser. That said, I believe it should still be possible for plugin vendors to distribute plugins as XPIs.

#### #9 Re: What about Firefox?

by berkut

Wednesday June 30th, 2004 12:48 PM

Plugins and extensions are different things! People keep mixing them up...

#### #11 Re: Re: What about Firefox?

by Yacoubean

Wednesday June 30th, 2004 1:22 PM

I don't want to start a flame war, but berkut, did you read my entire post? Because you did reply to my post, and I thought I made it pretty clear that I understand the difference between plugins and extensions. darwinwf reminded me that extensions don't work in other browswers, hence the need for a cross browser api. So what's your beef? ;)

#### #12 Re: Re: Re: What about Firefox?

by berkut

Wednesday June 30th, 2004 1:32 PM

Not quite, I stopped reading half way :) anyway, as I see it, XPI can be used as a vehicle to install plugins, but plugins need to be cross browser and xpi is not...

#### #21 Re: Re: What about Firefox?

by Yacoubean

Wednesday June 30th, 2004 10:23 PM

I don't want to start a flame war, but berkut, did you read my entire post? Because you did reply to my post, and I thought I made it pretty clear that I understand the difference between plugins and extensions. darwinwf reminded me that extensions don't work in other browswers, hence the need for a cross browser api. So what's your beef? ;)

#### #13 Re: What about Firefox?

by Mook

Wednesday June 30th, 2004 3:38 PM

The docs (linked from the mozilla.org press release) says this starts on Mozilla from 1.8a2; that would mean the code is on the trunk, and Firefox / etc. will pick up the changes when they go back to the trunk (looks to be post-1.0). Of course, if Ben et al. decide to backport the code to the aviary branch, that would happen by 1.0 - but that's not very likely, IFAIK.

#### #19 Re: What about Firefox?

by Gnu

Wednesday June 30th, 2004 9:26 PM

Weren't there XPI installers for Flash and Java versions for a while, or did I dream that?

#### #25 At least regarding Java, you're correct

by hobbes78

Thursday July 1st, 2004 3:32 AM

The Java Mozdev http://java.mozdev.org/ project provides XPIs for easy installation of Java within Mozilla.

In the company I work for, I first tried the official installation method but found that that doesn't work, probably because of the firewall. This XPI, though, works flawlessly.

#### #10 Separate process (or thread) for plugins?

by berkut

Wednesday June 30th, 2004 12:50 PM

I hope this time they make it impossible for a plugin to hog the CPU making Mozilla/Firefox unusable untill the plugin lets go of the CPU or finishes doing what ever it was doing...

#### #15 Here here

by Galik

Wednesday June 30th, 2004 4:23 PM

I totally agree

#### #16 What about Real?

by superyooser

Wednesday June 30th, 2004 8:15 PM

Aside from Microsoft, the only major plugin producer not yet in the alliance is Real. I hope they will join.

#### #18 Re: What about Real?

by arielb

Wednesday June 30th, 2004 9:13 PM

well there's also coolwebsearch but we'll let that be an IE exclusive feature :)

#### #20 Re: What about Real?

by zero0w

Wednesday June 30th, 2004 9:46 PM

I agree, Real should have joined the alliance if for nothing else, to offer the widest browser plugin support of its Media Players out there.

Apple's QuickTime plugin will fit into the picture too.

#### #29 real...

by zookqvalem

Thursday July 1st, 2004 10:58 AM

Well, Real will go open source soon. :-) Saw an article somewhere about it but Real had to wait for part of the software from other company to finish going open source first. That part is in process and haven't been released yet.

#### #23 Plugin Possibilities

by voracity

Thursday July 1st, 2004 12:37 AM

What I'd like is for these plugins to work at the raw text or markup level. e.g. You could download a plugin for native mathml, svg, css3, x* . . . whatever. Or even a plugin that renders, say, tex inline. (I know it's naughty, but I'd love to be able to do something like: 'in the <em> $c<\frac{b}{r}$ inequation</em> . . .')

bah, probably not a good idea. It's probably too difficult to implement and too open to abuse.

#### #24 Absolutely a good idea - what I'd like to see

by leafdigital

Thursday July 1st, 2004 2:20 AM

No, it *is* a good idea - that's exactly how plugins should work.

In addition to the current model (plugins support particular file MIME types) and enhancements to that model (allowing plugins to integrate with the page rendering engine so that you can have plugins underneath other things, transparent plugins, etc) which is presumably what is planned, a new plugin system should also allow for XHTML plugins that handle areas of the DOM tree specified by certain namespaces.

So you could have a MathML plugin, an SVG plugin, a MusicML plugin, ... that could all work with inline content rather than content from separate files. They could also handle standard DOM scripting, so in Javascript if you wanted to change something within your MathML equation or your SVG graphic (or create a new one on the fly) it would 'just work', as it works right now at least in theory with formats that are supported natively by the browser (i.e. MathML).

In Mozilla right now this would give the advantage of removing SVG code from the monolithic Mozilla project and making it entirely separate, meaning that those who want (unfinished) SVG support could simply install a plugin rather than having to use a completely different binary. Of course in the long term something as core as SVG might be used internally for icons and such, so it might be better to keep it inside, but...

You could make a TeX plugin like that if you wanted to, just have to namespace it like <tex:equation> or something, presuming you'd previously defined the tex namespace prefix. However, it would probably make more sense to use MathML, even though it's more longwinded.

I don't know if the new alliance is considering this type of issue, as there seems to be no technical detail available (perhaps discussions are only just beginning). I hope they are though as it would be a real win for XML; a standard, cross-browser way to implement browser support for your own formats, which would be very useful within niche interest, enterprise intranets, and so on.

Another thing I'd like to see is standard support for plugins in other formats apart from native binaries. Particularly Java support would be nice - since browsers generally already integrate with Java, it should be possible (not necessarily easy but possible) to allow plugins to be written as Java .jar files. Then you'd get cross-platform, cross-browser plugins that are easy to develop. (It would of course also be worth considering whether JavaScript plugins are a possibility too, as browsers provide JavaScript engines.)

Finally on the issue of XPI, which is of course orthogonal - XPI plugin installers for the common plugins would certainly be welcome if they could be designed to simply make the plugin work without any install user interface and not install crap all over your system that launches on startup/displays icons in your tray/etc. I can't see companies like Real going for that option though :)

--sam

#### #26 Re: Absolutely a good idea - what I'd like to see

by jgraham

Thursday July 1st, 2004 4:02 AM

Tangentially:

If you want to use TeX to generate equations, you might be interested in Itex2mml which converts a LaTeX-like equation syntax into MathML:

http://pear.math.pitt.edu/mathzilla/itex2mml.html for an introduction (don't use the download here)

http://golem.ph.utexas.edu/~distler/blog/archives/000290.html for the latest version

#### #27 Re: Re: Absolutely a good idea - what I'd like to

by jgraham

Thursday July 1st, 2004 4:16 AM

Sorry, the latest version is at: http://golem.ph.utexas.edu/~distler/blog/archives/000319.html

As for the main point of the thread, I guess having plugins rendr part of the DOM would be a lot harder than waht we have today because the plugin would have to interact very closely with the layout engine. I might, for example, want to embed SVG in a HTML document, use XBL to create bindings for the XBL and embed a HTML document in the resulting image - so it wouldn't just be a case of the plugin and browser agreeing on a size and position of a box for the plugin content and the plugin drawing to that box. I guess it's possible but I think that you'd need to design the layout engine from the ground-up to work in that way. It would probably also be slow.

#### #31 Re: Absolutely a good idea - what I'd like to

by voracity

Thursday July 1st, 2004 6:34 PM

Thanks.

Actually, I thought there was a javascript math tex to mathml convertor somewhere (i.e. drop the convertor in an onload, and sanitised math tex gets converted to mathml), but I can't find it on a quick search.

#### #28 Re: Argh...2

by roc

Thursday July 1st, 2004 5:50 AM

This would be nice, but incredibly hard. Gecko layout is tightly optimized and keeps evolving, so there will never be any frozen interfaces for people to target. Furthermore, new and interesting markup languages always require changes to the Gecko core to work well. (Markup languages that are undemanding can be implemented using XBL or XTF on top of our existing markup languages.)

#### #32 Gecko layout integration

by leafdigital

Friday July 2nd, 2004 5:09 AM

[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

#### #33 typo, knowing = nothing (n/t)

by leafdigital

Friday July 2nd, 2004 5:10 AM

sorry (n/t)