Mozilla has a problem with Firefox plugins and Flash. It is now considering supporting the Chrome solution to Flash and its Pepper API with Project Mortar. 

This is a strange story. Once upon a time there was a really easy way to extend the browser called NPAPI. Then plugins, particularly Flash and Java, acquired a bad reputation for security . So the browser makers decided that NPAPI was a bad idea. At the same time, however, Chrome introduced a native plugin facility called Pepper. This had the promise of allowing native code to run really fast and make web apps as good as native apps. Of course Mozilla refused to put Pepper into Firefox and so it remained a Google-only technology. The rest of the world moved to asm.js and eventually WebAssembly to try to make JavaScript run fast enough. 

Then NPAPI support began to be removed - Chrome already blocks plugins; Firefox is about to; and Edge never supported it. The problem is that Java, pdf and Flash support all come via NPAPI plugins. It seems Java support has mostly been ignored by the big browsers, but pdf and Flash are still important. Chrome and Firefox both still support Flash, but using custom interfaces to the plugins. Firefox uses a JavaScript implementation of a pdf reader and was on track to replace Flash in the same way with project Shumway. However, Shumway was closed down a the start of the year with no explanation. 

This leaves the lack of Flash support in Firefox a problem for Mozilla. 

Now Mozilla has quietly introduced Project Mortar, which plans to use Google's PDFium pdf reader and the Pepper Flash code to add both facilities to Firefox. Both projects are open source and there is only the technical problem of integrating them into Firefox. Of course, to use the Pepper Flash code there will have to be some support for Pepper built into Firefox and the question is why not go the whole way and support Pepper plugins?

Why is Mozilla moving to code produced by Google?

To quote the announcement:

"Project Mortar seeks to reduce the time Mozilla spends on technologies that are required to provide a complete web browsing experience, but are not a core piece of the Web platform. We will be looking for opportunities to replace such technologies with other existing alternatives, including implementations by other browser vendors. 

In order to keep costs low, we may use APIs internally that are not considered web standards. These APIs will not be exposed to the web. Solutions that both reduce our support cost, achieve the desired user experience, and make use of web standards will be preferred. "

So it seems to be a cost cutting exercise that won't lead to a full Pepper implementation, but will lead to the removal of NPAPI support in the near future. The big problem for the rest of us is that PDF and Flash aren't the only NPAPI users - why does no one worry about Java, for example?

Firefox has been losing market share and now competes for the fourth position with Edge, leaving Chrome way out in front. As a result Mozilla needs to cut costs and using other peoples code will reduce the effort it has to put into support - instead Google will pay for its upkeep. Of course, taking this to its limit means that Mozilla might as well simply fork Chromium and make a few cosmetic changes and let Google pay for the majority of the coding. Given that Mozilla is currently abandoning its XUL & XCOM architecture this isn't such a silly idea. 

The wasted effort of Shumway, replacing pdf.js with the arguably inferior PDFium, implementing partial and not full support for Pepper and using Pepper Flash all feel like a lack of planning and vision. Let's hope that this isn't another blind alley.

More Information

Announcing Project Mortar

Mortar Project

Related Articles

Mozilla Kills Shumway Its Flash Replacement 

Shumway - Flash In HTML5 Is Part Of Firefox 

Death Of Flash And Java Applets 

Shumway - Mozilla's JavaScript Flash Player       

Google Gets Closer To Killing Old Style Browser Plugins 

Chrome Drops Support For Plugins

Firefox Runs JavaScript Games At Native Speed      

Chrome Native Client Goes ARM and Portable       

Chrome native apps split the browser world       

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on, Twitter, Facebook, Google+ or Linkedin. 

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info