

The Final Countdown for NPAPI - cleverjake
http://blog.chromium.org/2014/11/the-final-countdown-for-npapi.html

======
dtf
I'm a bit sad that first Pointer Events which had support for pressure/tilt
from pen input got killed, and now NPAPI which drove the Wacom Plugin is also
dead. Seems there's no future route now to get pen input (eg Wacom, Samsung
S-Pen) into Chrome apps.

~~~
soult
I don't know what exactly you want to do with the pen input, but you could use
native messaging[0] to get the data into chrome. Basically a small, native
program that (bidirectionally) communicates with a Chrome extension via JSON.

I used the same approach to get customer signatures from a Wacom signature
tablet into a web app.

0: [https://developer.chrome.com/extensions/messaging#native-
mes...](https://developer.chrome.com/extensions/messaging#native-messaging)

~~~
ygra
But that's just a Chrome-only solution again, requiring you to use a different
method for each browser. A plugin at least gives you a few ones in one
solution.

~~~
AYBABTME
OP was asking about `Chrome apps`

------
adamrmcd
I understand the reasoning behind this, but this is super annoying, since:

1\. I am required to use GWT 2.5.1 for our java webapp

2\. I choose to use Chrome on Mac OS X

3\. Chrome 39 just auto-updated to support 64-bit on OS X

4\. Chrome 39 stopped supporting NPAPI

5\. GWT-2.5.1 and the GWT Chrome extension are not 64-bit compatible, and
require NPAPI.

6\. I have a major deadline this week finish styling our webapp

I've heard that enabling SuperDevMode can workaround all these problems,
however I'm just an HTML5/CSS3/GWT-UI-Binder developer, not a Java/Eclipse/GWT
expert. PITA.

(Perhaps I should enhance my calm and work on some LaTeX or Python)

~~~
teraflop
I find this kind of astonishing on the part of GWT. NPAPI has been deprecated
in Chrome for more than a year, and yet GWT's development mode still depends
on it?

~~~
cromwellian
The GWT team saw this coming a long time ago, that's why we undertook
SuperDevMode. It's not just chrome that yanked our APIs, Firefox removed
NPAPI, Safari make it incompatible with DevMode, and the rise of mobile
devices which don't run plugins, pretty make DevMode useless for mobile
development.

Our only options are to either ship our own browser fork, like Dartium does
and like we used to do with GWT < 2.0 Hosted Mode, or to make Javascript
debugging work. We opted for the latter.

In GWT 2.7, we can recompile million line apps in seconds, and with Source
Maps, and IDE support, you can back some of the original Java debugger
experience. In IntelliJ 14 in particular, it works very nicely. Folks are
working on Eclipse integration of SourceMap debugging.

NPAPI is a security risk and puts restrictions on other parts of the browser
internals and how they're represented. We can't prevent Chrome, Firefox, and
others removing this API just because of GWT.

Ironically, Microsoft might end up supporting this API forever, so GWT DevMode
might continue to work with IE.

------
McGlockenshire
Did they finally update the video chat parts of Talk / Hangouts to not need a
NPAPI-only plugin?

It was absolutely absurd of them to kill NPAPI in Chrome and not update Talk /
Hangouts accordingly. I ended up switching back to Firefox at work just so I
could use Hangout video chats again.

~~~
cleverjake
back in june - [http://www.cnet.com/news/in-chrome-googles-hangouts-
plugin-g...](http://www.cnet.com/news/in-chrome-googles-hangouts-plugin-goes-
extinct/)

I use video chats every day (on chrome canary os x) and never had an issue

~~~
McGlockenshire
Odd, it seems like I just checked the other week, but it has been a while.

It's also quite possible that the way they segment their product rollouts
between public and Google Apps for Business accounts might have meant that we
didn't get the update when I last checked it.

Using Chrome on Linux also might have something to do with it...

~~~
kentonv
> Using Chrome on Linux also might have something to do with it...

The switch to NaCl/WebRTC instead of the NPAPI plugin is what made Hangouts on
Linux actually starting working for me.

~~~
scrollaway
It also broke screenshare on Linux :(

------
drawkbox
So they are indeed going through with it. I thought they would push back a bit
since Unity isn't ready on WebGL and Silverlight is still used on Netflix. It
will be interesting to see how it plays out.

Hopefully Unity can get Unity 5 live and WebGL solid by April 15 latest.

~~~
bhouston
The Unity 5 WebGL programs are beasts to download. It is too bad there isn't
more ThreeJS-based development: [http://threejs.org](http://threejs.org)

~~~
drawkbox
Indeed three.js is more like the future but until the webviews in all mobile
devices run WebGL fast enough, Unity helps most on the mobile side and one
build so it is used. When WebGL runs fast across the board, many games can
just use that for all platforms. I personally love three.js but use Unity,
Lime/Haxe/OpenFL and Cocos because of mobile first.

------
cpeterso
Can Chromium use Chrome's Flash PPAPI plugin? Or will Chromium users, without
access to Flash PPAPI or NPAPI, have no Flash ?

~~~
xiaomai
Chromium can use Chrome's flash. Unfortunately, it's not distributed
separately from Chrome. This is how Arch LInux pulls it out:
[https://aur.archlinux.org/packages/ch/chromium-pepper-
flash/...](https://aur.archlinux.org/packages/ch/chromium-pepper-
flash/PKGBUILD)

------
shmerl
I wonder what will happen with Java applets once Firefox will try to switch to
Wayland. Flash is going to be replaced with Shumway, but Java will be left
behind. There is one case where I still use it (rather dumb Cisco Web VPN).

~~~
geofft
Have you seen if OpenConnect is capable of connecting to your VPN?
[http://www.infradead.org/openconnect/](http://www.infradead.org/openconnect/)

~~~
shmerl
Yes, but it uses that nasty trojan which doesn't work on Linux. So only
limited Java WebVPN (not full client) works in my case.

------
jimmaswell
It's really too bad that compatibility isn't cool anymore.

------
userbinator
With Google, it's _always_ about "security". Not security as in "you can
control what your software does", but as in "we'll do what we want to control
you and you _will_ like it."

The security issues were real, but I don't think trying to turn the browser
into one monolithic thing with everything bundled in it is the right way to
go. Unwanted plugins were extremely easy to block (no Flash -> no more
distracting ads) and allow for the sites you trusted, not so easy now with
everything integrated (and the way they're "simplifying" the settings and
hiding them just makes things worse.)

------
_random_
So transpilation to legacy languages is now the only option?

------
bratsche
Now I've got that "Final Countdown" song stuck in my head. :(

------
drvortex
What sort of moronic thinking leads developers to 'remove the override' for
advanced users?

~~~
ygra
So they can retire a complete feature, reducing complexity.

~~~
fixermark
Exactly.

The ideal future isn't one where only advanced users have access to NPAPI;
it's one where the browser doesn't support NPAPI at all, and (among other
things) Chrome no longer has to have a big pile of special support to launch
NPAPIs in their own separate process and transparently pipe all the important
bits to and from the browser's process.

