Since Google published the “NPAPI de-support statement for Chrome” on September 2013, it was a matter of time. And with Chrome R42, the April ’15 release it was a fact. The NPAPI got disabled. For Chromium, the Linux fork of Chrome, it was already with R35 by the way. Thanks to @lex for the notification. Since I was running with Chrome R41 I did not notice it (yet).
Now, the question is – what could the impact be? Obviously you should be using Chrome to have an impact. Although Oracle Siebel development is not promoting the use of Java Applet based integration (or any other browser plug-in), with Siebel Innovation Pack 2014 Oracle implemented… a Java Applet. Specifically meant for managing file attachments realizing like-for-like functionality conforming to the High Interactivity client. Basically the Java applet materializes two main functions:
1) It allows to open attachments with known extensions immediately after downloading the file
2) It allows edit & save-back
To realize both functions, it requires any type of browser plug-in, to bridge the gap between the browser and the OS. And a Java applet makes the most sense.
Well, this standard IP14 functionality will cease to work with Chrome R42. But so will any other Java Applet bespoke integrations. And for sure, there are a number of such integrations under development or in production. Since with OpenUI the ActiveX-based Siebel Web Client Automation framework is no longer a valid option, Java has been the resort of choice.
UPDATE: Google plans to take away NPAPI completely per September 2015.
For the time being Chrome allows to re-enable the NPAPI. There are basically three options:
- Entering “chrome://flags/#enable-npapi” in the address bar, select “Enable” and “Relaunch” Chrome.
- Start Chrome using an addtional swith “–enable-NPAPI”
- Through Group Policies using Chrome Administrative Templates. This allows to enable NPAPI plug-ins selectively. .
Next question is when Firefox will move in the same direction? For Internet Explorer, the Java Browser Plug-in is ActiveX based. But a valid question is whether the new “Spartan-generation” browser will support the NPAPI framework. Spartan will quite surely not support ActiveX 🙂
Talking Spartan, recently Microsoft released it for beta testing along with Windows 10. First results are not very promising.
Spartan is meant to be, well, Spartan. Internet Explorer is commonly viewed as bulky and slow, and Microsoft wants to fix that perception. Unfortunately, Spartan doesn’t do as much as expected to challenge user preconceptions.
Spartan has a new Web browsing engine called Edge. Well, kinda new. It’s actually a fork of Trident, the browser engine used by Internet Explorer, but changed to improve Web standard support and performance. Presumably, the gap between it and Trident will only grow over time, as Microsoft says that Internet Explorer’s legacy engine won’t receive any of Edge’s updates.
For now, though, it seems that Edge is not far removed from its predecessor. We started out testing with the Peacekeeper Web-browsing benchmark, a test that broadly covers numerous performance metrics, and it gave Spartan no advantage.
The excellent Octane result may explain the feel of the browser, which is quicker than the benchmarks suggest. In typical use, on Web pages that don’t include games or video, Spartan feels just as snappy as Chrome and actually quicker than Firefox. Pages scroll smoothly, even when they include numerous intensive elements, such as high-resolution photos, with no hint of unsightly check-boarding (on our desktop with an Intel quad-core, at least). Multiple tabs eventually slowed the browser, but only after opening 15 or more.
So I can safely end a bit more positive on the Spartan project. Unfortunately Spartan will only be released on Windows 10. No backport as of yet to Windows 7 / 8 (even if it were technically feasible). And we can safely say that it will take years before enterprises will change from Windows 7 to 10 (my guestimate).