Slashdot Mirror
Ask Slashdot: Options After Google Chrome Discontinues NPAPI Support?
An anonymous reader writes: I've been using Google Chrome almost exclusively for more than 3 years. I stopped using Mozilla Firefox because it was becoming bloated and slow, and I migrated all my bookmarks etc. to Chrome. Now Chrome plans to end NPAPI support — which means that I will not be able to access any sites that use Java, and I need this for work. I tried going back to Firefox for a couple of days but it still seems slow — starting it takes time, even the time taken to load a page seems more than Chrome. So what are my options now? Export all my bookmarks and go back to Mozilla Firefox and just learn to live with the performance drop? Or can I tweak Firefox performance in any way? FWIW, I am on a Windows 7 machine at work.
Have a question for Slashdot's readers? Take a look at other recent questions first to see if someone else has had a similar question. And if not, ask away! The more details and context you include, the more likely your question will be selected.
http://lifehacker.com/turn-on-... I've noticed a speed bump doing that, and the usual addons for ad blocking etc.
http://chimpbox.us
From the Chromium Blog:
In April 2015 NPAPI support will be disabled by default in Chrome and we will unpublish extensions requiring NPAPI plugins from the Chrome Web Store. Although plugin vendors are working hard to move to alternate technologies, a small number of users still rely on plugins that haven’t completed the transition yet. We will provide an override for advanced users (via chrome://flags/#enable-npapi) and enterprises (via Enterprise Policy) to temporarily re-enable NPAPI while they wait for mission-critical plugins to make the transition.
Tweak firefox with:
new tab, type "about:config" into the address bar.
find "network.http.pipelining" and set it to "true"
find "network.http.pipelining.max-optimistic-requests" and set it to 8
find "network.http.pipelining.max.requests" and set it to 32 if it isn't that already. Don't take this one too high.
They sentenced me to twenty years of boredom
Google announced in September 2013 that it would phase out NPAPI support in Chrome during 2014.
NPAPI support is disabled by default since April 2015 (version 42) for Windows and OS X, but can be turned on in the settings.
Google plans to drop Chrome NPAPI support from all platforms in September 2015.
I wont call 2 years warning aggressive. I would call it more then a fair warning.
And if web-apps or plug-in's are not up to modern standards by now. Then extending to time they have to fix it wont help. Because the only things that's not updated by now wont be as long as they do not have to.
Now they are being forced to do it. And it comes as a chock for some that they only got 2 years warning.
Per the Java support site, go here: chrome://flags/#enable-npapi
They probably won't support enabling it forever, but for now it's a workaround.
Use Seamonkey.. It looks old, and it's at least as fast as Firefox, and with better security options. It has an email client, and an HTML editor, it'll play all the latest videos, and make popcorn. It's the browser that does everything, and it only weighs a few meg more than Firefox. It's a *Full Figured* browser.
“He’s not deformed, he’s just drunk!”
Here's the Firefox bug: https://bugzilla.mozilla.org/s...
Mod me down, my New Earth Global Warmingist friends!
Surely it's not because Pepper is designed first and foremost for Chrome, rather than being easy to adopt, like NPAPI was?
Actually, the reason is that it would require widespread adoption of the Chrome sandbox model, which is integral to the implementation.
Oracle can't even get its own products to work properly with Java.
This has been Addressed by FreshPlayerPlugin allowing FireFox to use PPAPI
That is the intent of static typing and static declarations. However, just because that may be a good thing doesn't mean it's the only way to make a language type safe. Dynamically typed languages are (usually) type safe, just like statically typed languages; they simply detect type errors at runtime.
In reality, it's a good thing to have both static and dynamic typing available in your programming language, and that's what programming languages increasingly are doing (C++, Java, C#, Swift, Objective-C, CommonLisp, etc.). The addition of dynamic typing doesn't make a statically typed language type-unsafe. Some of those languages choose dynamic typing as the default for variables without a type, others require dynamic types to be declared explicitly; that, too, doesn't affect type safety.