Goodbye firefox.
Mozilla to boot all plugins from Firefox … except Flash
The Mozilla Foundation has revealed that some future versions of its flagship Firefox browser will ship without support for plugins of any sort. The organisation yesterday announced that “new platforms such as 64-bit Firefox for Windows will launch without plugin support.” Adobe Flash is the exception to the rule, because it …
COMMENTS
-
-
Friday 9th October 2015 03:36 GMT Anonymous Coward
Poor old moz has been slowly slipping away since its soul was sold to google fifteen years ago. That was when it ceased to innovate, ceased to evolve and ceased to function in the interests of its "community" (which died practically instantly). The braindead narcissists at the top, obsessed to obliviousness by their demented pie-in-the-sky whimsy, are the ONLY ones who couldn't (and STILL can't) see it.
RIP Netscape.
-
-
-
-
-
Saturday 10th October 2015 03:24 GMT John Tserkezis
Re: Mplayer
"It's confusing that in English, "plugin" and "extension" are pretty synonymous, but in Mozilla products, they mean distinct things."
Don't forget "addon" either. Worse still googling "plugin" will take you to the addon site. Too bad the article didn't explicitly exclude "extension". As if the naming conventions aren't confusing enough - one can be forgiven for confusing them.
-
-
-
-
-
This post has been deleted by its author
-
-
Friday 9th October 2015 05:02 GMT Chairo
Re: So no AdBlock, NoScript, or RequestPolicy then
those are extensions and will still be available
Thanks for pointing this out! Have an upvote. Perhaps that should have been mentioned in the article itself.
I still think they should make it possible to opt-in to plugins for the few people that need them. As it is, Firefox is the only popular browser left with plugin support and there are some legitimate uses.
-
Friday 9th October 2015 12:59 GMT Anonymous Coward
Re: So no AdBlock, NoScript, or RequestPolicy then
"I still think they should make it possible to opt-in to plugins for the few people that need them."
No, because that would imply that the FireFox folks still embrace giving the users a choice in how they use the browser. And if there's one thing that the FireFox folks have shown in recent years, it's that they don't give a damn about that. Use it they way they intended it to be used, or be damned. And if you don't like the increasingly dumbed-down interface and options available, well, tough-shit. And did they take out functionality that you used to like? Well, boo-hoo - give them a bunch of use cases that they'll accept and agree to and maybe they'll merely tell you to fuck off instead of telling you to go hang.
https://bugzilla.mozilla.org/show_bug.cgi?id=838681
Bitter? Me? no...well, maybe just a little..
-
-
Friday 9th October 2015 05:27 GMT raving angry loony
Re: So no AdBlock, NoScript, or RequestPolicy then
Ah! Thanks for the clarification about "extensions" vs "plugins". The article would have done well to differentiate between the two. I probably knew that, but I know that I've always lumped "plugins" and "extensions" together as "plugins", and I'm probably not the only one.
-
-
-
Friday 9th October 2015 09:51 GMT Spacedman
Re: So no AdBlock, NoScript, or RequestPolicy then
Just stick "about:plugins" in the URL to see what plugins you have installed with version numbers and paths and all that icky technical stuff they don't want you to know.
Go to "about:addons" and get a more fruity page where you can also list "Extensions" (which aren't going away) as well as the "Plugins".
My big gripe is the VMWare web interface plugins - they are NPAPI and so don't work on Chrome, and VMware show no sign of porting them. My current solution for VMware host management on Linux is Firefox with Pepper Flash via FreshPlayer (so I get a high enough version number of Flash) and the VMware plugins via NPAPI. Fragile as heck.
-
Friday 9th October 2015 10:31 GMT Wensleydale Cheese
Re: So no AdBlock, NoScript, or RequestPolicy then
Just stick "about:plugins" in the URL to see what plugins you have installed ...
Many thanks. Despite having things like NoScript and ad blockers installed, in "about:plugins" I only see a couple and those are from Cisco (web conferencing stuff).
IMHO muich confusion is caused by the way FF itself lumps stuff together as Add-Ons.
-
-
-
-
-
Friday 9th October 2015 11:02 GMT Dan 55
Re: So no AdBlock, NoScript, or RequestPolicy then
Extensions are in fact going to be dropped too.
https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/
After reading this about them dropping NPAPI after having read about them them dropping XUL extensions, I now think Mozilla don't have any idea what they've got and are just dumping features that aren't in WebKit and making it look more like Chrome.
What's the other thing they've got... privacy. Only they also changed the Sync protocol and haven't bothered to explain how to set up a private server.
-
Friday 9th October 2015 13:01 GMT Tom 13
Re: So no AdBlock, NoScript, or RequestPolicy then
No Dan, your link just says they're changing how you build them, not dropping them:
We are implementing a new extension API,
Frankly, if your extension supplier isn't keeping up with current architecture, it's malware prone anyway.
What's that? Why yes, software developers who don't keep up with current architecture IS a pet peeve of mine. Primarily because as a desktop support tech I have to support a critical app in my environment that is created in-house by a bunch of twits who keep insisting that we keep users on old malware prone versions of Java for their IE-required web app. Granted, they have improved in the five years I've been here. Now they're only running one or two versions back whereas when I first started Java was well into the mid 1.6 range and they still insisted on having 1.5.16 installed. I mean, they were so far behind even Sun had removed the installer from their archive.
-
Friday 9th October 2015 13:18 GMT Dan 55
Re: So no AdBlock, NoScript, or RequestPolicy then
No Dan, your link just says they're changing how you build them, not dropping them:
It says "We have decided on an approximate timeline for the deprecation of XPCOM- and XUL-based add-ons" which is the last half of 2016.
So developers can either rebuild them with WebExtensions or you leave them as XUL, which means they will be dropped when Firefox stops supporting XUL extensions. There are many extensions that aren't actively maintained but still work because they follow the XUL extension spec. There are many extensions that are maintained to fix small bugs but the developer doesn't have time to rewrite them for the latest API du jour.
XUL extensions and NPAPI support are both strong points for Firefox. Why are they out-of-date architectures? Getting rid of them is a great inconvenience to users.
I imagine they don't update on the day because they have to test if the update breaks anything first. If you have to support browser-based or webstart Java, your job will be so much fun when NPAPI disappears from Firefox.
-
Friday 9th October 2015 21:22 GMT Cryo
Re: So no AdBlock, NoScript, or RequestPolicy then
"Extensions are in fact going to be dropped too."
"No Dan, your link just says they're changing how you build them, not dropping them"
Actually, in many ways they ARE dropping extensions as we know them, and replacing them with what amount to "Chrome-compatible" extensions. Firefox has had an extension system that gives a lot of control to extension developers, and in turn anyone using those extensions. They're getting rid of much of this advanced functionality, so extensions will be quite a bit more limited in what they can do. Many existing extensions simply won't be possible to port to the new system, or they'll need to drop major features in order to work with it. While it may not be the topic of this article, it is likely to be something that's going to upset a lot of people when it happens.
"After reading this about them dropping NPAPI after having read about them them dropping XUL extensions, I now think Mozilla don't have any idea what they've got and are just dumping features that aren't in WebKit and making it look more like Chrome."
I suspect their ultimate plan may be to go the Opera route, eventually discontinuing their browser and replacing it with a low-maintenance Chromium re-skin with a few extensions built-in, that they can profit off of without spending any significant development budget on. These are the same kinds of things Opera was doing before that happened, and why the "Opera" desktop browser of today is just a generic featureless Chrome-derivative instead of the feature-packed Internet suite it once was. They may very well be making their browser look and behave like Chrome in an attempt to ease the transition.
-
-
Friday 9th October 2015 19:24 GMT oneeye
Re: So no AdBlock, NoScript, or RequestPolicy then
EXTENSIONS ARE NOT BEING DROPPED !! Read the blog at the link you posted. Good grief man,stop spreading FALSE rumours. Mozilla is modernizing,and improving the APIs to make them more safe,and compatible with all other,major browsers,ie. Chrome,Opera,and possibly MS Edge.
Ghostery,Adblock Plus,and other well developed add-ons will have no trouble migrating to the new setup. For other,less experienced developers,there is a ton of help available. Again,read the blog,...slowly,and completely,and if necessary, rinse and repeat (-:
-
Saturday 10th October 2015 08:33 GMT Dan 55
Re: So no AdBlock, NoScript, or RequestPolicy then
I have read the blog, let me summarise for you. XUL support will be depreciated. XUL extensions must be rewritten using the WebExtension API. WebExtensions aren't as powerful so some XUL extensions can't be rewritten. Those XUL extensions that aren't being actively maintained or those that require too much work to be rewritten than the developer has time for also won't be rewritten. A lot of extensions will become incompatible with no substitute. Firefox has jumped the shark.
Consequently, we have decided to deprecate add-ons that depend on XUL, XPCOM, and XBL. We don’t have a specific timeline for deprecation, but most likely it will take place within 12 to 18 months from now. We are announcing the change now so that developers can prepare and offer feedback. Add-ons that are built using the new WebExtension API will continue to work. We will also continue supporting SDK add-ons as long as they don’t use require(‘chrome’) or some of the low-level APIs that provide access to XUL elements.
A major challenge we face is that many Firefox add-ons cannot possibly be built using either WebExtensions or the SDK as they currently exist. Over the coming year, we will seek feedback from the development community, and will continue to develop and extend the WebExtension API to support as much of the functionality needed by the most popular Firefox extensions as possible.
-
-
-
-
-
This post has been deleted by its author
-
-
Friday 9th October 2015 07:15 GMT Anonymous Coward
Yes, really. Haven't you heard the stories of critical network control systems (worth six figures or more) being dependent on Flash to operate? This is a serious case of Flash being "too big to ignore". Kill Flash, and you kill your customer base as they're forced to other browsers just to stay operating. In such an environment, you pretty much don't have a choice. So Mozilla are working the other way and trying to nurse Flash to make it as trouble-free as they can. They're also trying to encourage web developers to switch to alternatives (though it's noted some devs are stubborn). Plus as noted in the past, they're trying to make a drop-in alternative to Flash with Project Shumway.
-
Friday 9th October 2015 09:14 GMT Tony Paulazzo
So Mozilla are working the other way and trying to nurse Flash to make it as trouble-free as they can.
So, kind'a like Chrome then. Sandbox the effing thing and be done with it.
Now that readers (as opposed to the article), have clarified they're not getting rid of extensions, I can rest easy, I've only got Flash addon and some openH264 video thingy in there.
-
-
-
-
Friday 9th October 2015 04:58 GMT P. Lee
>Getting rid of plugins, but keeping Flash and Java? That's the exact opposite of a good idea.
but pragmatically the right thing to do. Kill the API but keep the two which people use during a deprecation period. Some people will still want porn and some will run enterprise apps. Both will still be on death row.
What other plugins are there?
-
-
Saturday 10th October 2015 03:50 GMT Kiwi
I hope these companies get their act together and develop new ways of viewing CCTV via browsers without the need of special plugins for their existing DVRs.
Just had to deal with that in the last few days. Told the customer to return the unit to the supplier and say the $NZ800+ system was not fit for purpose due to requiring the customer use I don't know what version of IE (we tried from 6 to latest on XP, Vista, 7 and 10) and some ActiveX thingy downloaded from the DVR. Simply would not work, and no other way to view except ActiveX.
Real glad because I had been considering these units as we want to expand our existing system. At least I know not to touch them now. Or trust that supplier.
-
-
-
Friday 9th October 2015 04:21 GMT tjdennis2
Don't confuse plugins with extensions
FireFox is not getting rid of extensions, just the binary plugins which software companies might install on FireFox like video codecs, SilverLight, etc. Think of them like the ActiveX controls in Internet Explorer that everyone has always hated.
Personally, I think they should dump Flash as well since they set the date at Dec 2016. Apple never supported Flash on their iPhones and iPads and we survived that perfectly well. No excuse for web sites not to convert to html5 in the next 15 months if they care.
-
Friday 9th October 2015 14:04 GMT Anonymous Coward
Re: Don't confuse plugins with extensions
"FireFox is not getting rid of extensions, just the binary plugins which software companies might install on FireFox like video codecs, SilverLight, etc. Think of them like the ActiveX controls in Internet Explorer that everyone has always hated."
Wrong. They're dropping XUL at the same time.
-
Friday 9th October 2015 17:51 GMT Geoffrey W
Re: Don't confuse plugins with extensions
RE: Wrong. They're dropping XUL at the same time.
Incomplete: They're replacing XUL with a different API, so not dropping extensions. All popular extensions will no doubt be ported: if not then they probably aren't being updated much either and on borrowed time anyway.
-
Monday 12th October 2015 17:46 GMT Charles 9
Re: Don't confuse plugins with extensions
Six of one, half a dozen of the other. Changing the API means old extensions will get dropped, as well those that use XUL that have no counterparts in the new API.
"All popular extensions will no doubt be ported: if not then they probably aren't being updated much either and on borrowed time anyway."
But why fix what isn't broken?
-
-
-