The Final Countdown for NPAPI | Hacker News Reader

The Final Countdown for NPAPI

blog.chromium.org

90 pointscleverjake70 comments

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.

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...

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.

OP was asking about `Chrome apps`

Thanks! I'll look into that.

Currently I'm piping evdev (ie /dev/input/event*) events through a WebSocket for use in my own personal apps/experiments on Linux. I'd love to see browser pen support though... maybe something could be added to Touch Events? It's just such a nice, precise form of input.

Actually, there is an implementation of Touch Events (the Microsoft one) that already supports all this...

Is that Microsoft's "Pointer Events" that Google has decided not to support?

http://arstechnica.com/information-technology/2014/08/google...

Chrome team is planning to extend the touch events with stylus-specific functionality: https://docs.google.com/a/chromium.org/document/d/1x-yE4CmTZ...

What do you mean by Point Events getting killed? Here's the http://www.w3.org/TR/2014/WD-pointerevents-20141113/

I guess they mean that Chrome won't implement Pointer Events: http://arstechnica.com/information-technology/2014/08/google...

Ah, I didn't hear about this. Too bad.

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)

This is a par-for-the-course complaint about NPAPI plugins (since they're binary, they're beholden to all the issues of 32-bit 64-bit compatibility, compile to the operating system, etc., etc., etc.).

Given the improvements in JavaScript performance and webgl over the past half-decade, it's a small wonder that browser maintainers want to kill NPAPI support as fast as possible. It's a bad experience for them, generally a complex experience for end-users, and essentially a massive hack.

Yes, but then how do you enable support for things that the browser doesn't give you (e.g. someone else talked about pen/stylus input devices)? How do you write something like It'sAllText for Chrome? Current NPAPI-less solutions involve the need to run a separate server to communicate with, which launches the $EDITOR process.

You don't, by design. You improve the browser to expose the functionality you need with a sandboxed API, or you communicate with a separate program that runs entirely outside the browser.

If you want to support a pen or stylus, you add a pen/stylus API to Chrome.

I've been waiting for an API addition, that I had been personally assured by Chromium PM would go through, for 4.5 years. It's needed to support full canvas screenshot functionality in ChromeDriver, so it's not exactly a fringe use case. Given the time it takes for some of this stuff to go through, NPAPI was at least an option. That's the point of a plugin API after all ... so not every use case needs to be accounted for by the parent project.

I realize there are security issues and all that. But it's not as simple as hoping Chrome will just add the API you want either, in my experience.

> You improve the browser to expose the functionality you need with a sandboxed API, or you communicate with a separate program that runs entirely outside the browser.

What is your response to the 'browser is bloat' crowd then? Your solution is to add functionality to the browser even for people that don't need it. Doesn't this lead to bloat in the browser itself?

If I want to support a pen in Chrome, and the way to do it is to modify Chrome, I am going to give up. I do not have the skill to do that. If I have to learn an entire different programming language to do something, I just don't have the time to do it right now.

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?

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.

SuperDevMode[0] has been a thing for the past year or 2 (which doesn't use the NPAPI plugin). The GWT team just released GWT 2.7 which makes SuperDevMode the default development mode (they also added incremental compilation which rocks).

GWT is ready for it, the problem is that most people that use GWT are doing it in "enterprise" world, where upgrading libraries is super painful.

[0] http://www.gwtproject.org/articles/superdevmode.html

Download an older version of chrome, and turn off auto updates.

I had to resort to Firefox 24 on OS X, however I found a Chromium 38 build. Guess that'll do for now.

http://www.freesmug.org/chromium

Could not find any older builds of Chrome for OS X

(updated to say I'm on OS X)

Maybe this will help http://google-chrome.en.uptodown.com/mac/old (fair warning, I didn't actually tried to download/use any of these).

That's perfect! .. Insta-bookmark!

Although I did find Chromium 38 did work to get me back online, this uptodown site will prove useful for other tests requiring full Chrome.

Thanks!

https://www.modern.ie/en-us/virtualization-tools#downloads

www.oldversion.com/windows/google-chrome/

Two months from now: "what kind of moron turns off auto update? You deserved to be pwned!"

This whole thread is based on OP's need for GWT Chrome extension to develop his company's webapp. So presumably OP can have a old Chrome version just for web development and a separate browser for his regular browsing needs. I doubt OP will get pwned by his own company's internal development site.

Simultaneously running a safe browser and an unsafe browser and hoping you never open a link in the wrong one seems fraught with peril.

google "portable chrome".

problem solved.

Did you actually try it? It's almost impossible to get a hold of the old versions of chrome now. Google tool down almost all of them.

No, thankfully I'm not in a position to need to. I'm just commenting on how ludicrous the situation is.

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.

back in june - http://www.cnet.com/news/in-chrome-googles-hangouts-plugin-g...

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

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...

> 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.

It also broke screenshare on Linux :(

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.

Netflix no longer requires Silverlight in Chrome.

True, still a ton of cleanup, old silverlight video/content/systems to clean up. I bet content costs are a little higher as well with many formats having to be pushed to the edges rather than one VC-1 format.

I wonder why haven't they moved all systems/browsers to it if their html5 player side and content is up to speed? I usually watch in Safari because I work in Chrome/Firefox for dev typically.

Hi, I work at Netflix.

We switched from VC-1 to H.264 a few years ago, so the encodes don't change with the switch from Silverlight to HTML5 video.

Currently just IE 11, Chrome, and Safari 8 in Yosemite support our HTML5 player. It depends on three new APIs in HTML5: MSE, EME, WebCrypto.

Shameless plug: I'm currently hiring for the engineering manager of the team that builds our HTML5 streaming video player. http://jobs.netflix.com/jobs.php?id=NFX01593

IIRC, Netflix uses a no plugin mode in Safari on Yosemite.

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

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.

The size is pretty much fixed regardless since it's usually game assets and audio/video that blow the sizes up, especially retina stuff.

There's always flash and javascript games if you're looking for games that are optimized for file size.

I find webgl to be completely unusable on linux; I have one box with a radeon and another with an nvidia. The nvidia one kind-of-sort-of works.

I had to completely turn off accelerated rendering in chromium on the radeon box, or I would get extreme display corruption on even on non webgl pages.

Are you sure this isn't a subset of the problem of "3D graphics on Linux?"

I assume you've verified against other 3D apps on those machines that the graphics stack itself is standards-compliant.

the nvidia box is definitely more solid than the radeon; the nvidia one does every 3d game I've thrown at it with no noticable issues. However, it's blacklisted by chrome for webgl, and when I tried forcing it, there were definite stability issues.

The radeon box, however, has noticable z-ordering artifacts and some minor flickering on games. Chrome is by far the worst application for it though, web gl or no web gl.

I have a box with Intel HD 4000 graphics (Ivy Bridge, when Intel graphics started being half-decent) and WebGL is great on Linux.

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

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/...

On Debian and Ubuntu, you can install the "pepperflashplugin-nonfree" package to download a copy of Chrome and extract the PPAPI Flash plugin therein and install it.

http://packages.ubuntu.com/pepperflashplugin-nonfree https://tracker.debian.org/pkg/pepperflashplugin-nonfree

Since Chrome is just a repackaged Chromium, you can copy all the libraries from the Chrome download. Including both flash and libpdf.

Yes you can, I do it on gentoo.

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).

Have you seen if OpenConnect is capable of connecting to your VPN? http://www.infradead.org/openconnect/

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.

Separate firefox in a X server. A lighter version of what some of us need to do online banking - IE6 in a WindowsXP VM.

Cisco has many other VPN alternatives.

Yeah, that's not the question of alternatives. It's the question of what one has to use with some stuff where requirements come from elsewhere.

I would assume it will go the way of other situations I've seen where embedded software depends on a specific version of a browser: the enterprise in question will lock the acceptable in-house browser version until such time as risk / cost of lack of security support outweighs risk / cost of changing their add-on solution.

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

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.)

So transpilation to legacy languages is now the only option?

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

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

So they can retire a complete feature, reducing complexity.

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.

It's exactly that kind of thinking that worked so brilliantly for Firefox, isn't it?

Reply on news.ycombinator.com