No, absolutely not. That would mark a real position, and maintain a competitive advantage for Mozilla in enterprise environments (where browsers are used for more than playing games and watching videos, and plugins are not substituted from one day to the other).
Apart from that there is nothing wrong with npapi. It's about how it is used, how stable the plugin is, and how trustworthy the vendor of a plugin is. The risks that are involved are the same as for any software, mostly less with sandboxed plugins.
I think, taking away NPAPI is taking away a piece of freedom from the user - the freedom to use plugins. And freedom is just what Mozilla was standing for, a long time. Instead of taking away NPAPI, they should implement a mechanism for trusted plugins, e.g. to load/execute them only when they are cert signed.
> I'd be curious how they are planning to support extensions like vimperator or even no-script.
That will not be supported anymore. Regardless of the user's desires.
They want you to consume media and buy their apps in the browsers app store. That's all you are supposed to do with your browser in the future vision of Google, Mozilla & Co.
Time for a revival of fat client desktop applications, even if they mainly display HTML content or call web services...
> OTOH, maybe this is a win. We need to get away from this
> whole "The browser is a poor man's operating system" model
> anyway. Let the browser do a great job of browsing
> hypermedia
Yes that is the only win I can see as well. Obviously they want to turn browsers from general kitchen utensils to pure entertainment and amusement platforms, for media and information consumption.
(Hm wait, wasn't that what the WWW was supposed to be, back in its early days? Are we going back to the dark ages or is it just the usual turn of history?)
Interresting project :). Every project in this direction is thriving and fun, no doubt. I am happy to see these developments, hopefully they go on!
The browser plugin on the other side is mature and fits in where EmTcl, NaTcl etc. leave off: when it comes to use the full feature set of Tcl and its huge extension library, including Tk windows, in the browser and in production code. Intranet web applications maybe, e.g for the use cases I mentioned above. Therefore it still has its niche, I think.
But maybe it will be possible to do things like sockets on arbitrary ports with arbitrary protocols, or driving external hardware, with EmTcl in the future? That would be great :-)!
Depends.
Lets say you have a service that is running on your local PC at some port >1024. It uses a special binary TCP protocol and controls hardware from which images are coming in live stream. You want to display these images in a browser window, on the way there you want to resize them. And then you want to use them in the web application where the window is embedded. You have a stable tested Tcl library to do this in normal client environments, but now the requirement is a web application.
How would you get Javascript and emscripten to do this task?
I think there are two points, where a browser plugin is still relevant: (1) connect with hardware or resources where a browser has no access, from a web page. That is when you can write a little companion Tclet to do exactly this little task. (2) Deployment of an existing Tcl application to thousands of users. That's so much easier when you just need to drop the .tcl file on a web server, and your users get the update as soon as they press F5 in their browser to reload the page.
http://kmeleonbrowser.org/
http://www.gnu.org/software/gnuzilla/
http://www.seamonkey-project.org/
All based on the Gecko engine. I wonder what their standpoint is about NPAPI, though.
I use kmeleon and I am quite happy with it.