Were there ever non-x86 NPAPI plugins?

[Basilisk-Dev]

Were there ever any non-x86 NPAPI plugins on Linux systems? If so, what were they?

I suppose in theory you could compile GNU GNASH or Lightspark NPAPI plugins for non-x86 systems, but I am moreso asking about official/popular plugins such as Adobe Flash.

If there were not NPAPI plugins for non-x86 architectures, is it even worth compiling UXP applications on non-x86 with the NPAPI support enabled?

[Pentium4User]

Adobe Flash existed for amd64 (x86_64).

[Basilisk-Dev]

Adobe Flash existed for amd64 (x86_64).

Sorry if it wasn't implied that x86 included 64-bit x86 as well. I had assumed that the implication was obvious. I was referring to anything that is not x86 compatible in any way (for example, ARM or SPARC).

[Pentium4User]

IIRC ARM was not used in desktops when NPAPI was widely used.
A version for Solaris on SPARC existed: https://community.adobe.com/t5/flash-pl ... -p/3156210

[athenian200]

I think there was an ARM version of Flash for Chromebooks and Android at one point... don't know how well it would work on modern Linux, though. However, I'm pretty sure there was an ARM version of the old Java NPAPI plugin that might work.

And yeah, Solaris had plenty of NPAPI plugins for SPARC like the guy above me said, but aside from that I don't think many other architectures ever had it. It's mostly an IA-32/AMD64 thing. Maybe there was an Itanium version, but Itanium is pretty dead. On Mac, I do believe PPC had some NPAPI plugins. So really it's mostly older, more established architectures that were once used on desktop. SPARC was used at one point by some Sun workstations, and Mac used to be PPC, and that's why those architectures have NPAPI plugins.

However, right now it's a bad idea to disable NPAPI support because there are a few issues that have been found with my build flag for doing so. For one thing, WebRTC currently depends on NPAPI, and Travis just found that mouse wheel scrolling doesn't work without NPAPI right now either. I'm trying to tracking that latter issue down, and hoping to find a way of fixing that that won't involve adding half the NPAPI back in despite the build option saying it disables it... seems kind of pointless to have a build flag that partially disables NPAPI if there's supposed to be a way to disable it.

But yeah, if you want the "full" experience, the Windows on IA-32/AMD64 version is always likely to be the "flagship" version of the browser because it's the platform on which NPAPI works best. Everything else is kinda compromised and broken in that regard. Linux already has issues with NPAPI due to GTK3 and later, plus Wayland and newer glibc, and the increasing adoption of ARM on Mac is making things more difficult on that platform as well. If AMD64 ever gets fully replaced by ARM or RISC-V, then NPAPI is as good as dead on all platforms.

[Moonchild]

I did build an x86_64 version of a PDF reader, and there's really nothing stopping anyone from building for ARM, M1SoC, SPARC, Risc or similar. The NPAPI is an API that doesn't care about the actual binary code as long as the API's messaging is followed, it will work.

[athenian200]

That's a good point. I guess if we want NPAPI to have a future, there need to be more open source NPAPI plugins that can be compiled on newer platforms. The API itself isn't the problem, the problem is that most of the stuff people want to use on it is commercial binaries that are no longer produced.

[Pentium4User]

That's a good point. I guess if we want NPAPI to have a future, there need to be more open source NPAPI plugins that can be compiled on newer platforms. The API itself isn't the problem, the problem is that most of the stuff people want to use on it is commercial binaries that are no longer produced.

Because FF and Chrome don't support it anymore, almost all vendors discontinued it.
I don't think there will be something new here.

[mrnhmath]

I don't think there will be something new here.

People are also generally unaware of the existence of a truly independent web engine and platform. yet here we are. We just need to get interested parties aware of the potential of the NPAPI technology.

[Pentium4User]

I don't think there will be something new here.

People are also generally unaware of the existence of a truly independent web engine and platform. yet here we are. We just need to get interested parties aware of the potential of the NPAPI technology.

Te question is just: Which benefit does it provide?
Adobe Flash prospered at a time when browsers weren't able to play videos.
Now HTML 5 exists.
Most browsers also support PDF viewing inside them - other people can still use their favorite PDF reader.

Which use-cases you think about?

[athenian200]

Te question is just: Which benefit does it provide?
Adobe Flash prospered at a time when browsers weren't able to play videos.
Now HTML 5 exists.
Most browsers also support PDF viewing inside them - other people can still use their favorite PDF reader.

Which use-cases you think about?

When it comes to Flash, I don't really think HTML5 is a good replacement for everything Flash can do, but Ruffle's ability to simulate it using WebAssembly comes a lot closer, so the argument has merit even if we disagree on the specifics of what counts as a replacement for Flash player.

There's also stuff like Silverlight, Shockwave, Java applets, the Unity web player, plus more obscure uses.

Having to rely on a PDF reader as functionality baked into the browser rather than having a selection of optional extensions is antithetical to our philosophy, but it does raise another point... couldn't a PDF reader just be implemented as a XUL extension rather than an NPAPI plugin? It's an interesting thought.

One use case I am considering, is using an NPAPI plugin to recreate a modern IE Tab using WebView2. Though honestly I'd rather put that effort into improving UXP itself, it is something that is on my agenda to try some day. The point is, it does offer ways of adding functionality to the browser without having to bake things into the codebase. So far the benefits are only theoretical, because it's just being used to load legacy plugins, but in theory there might even be ways of adding newer technologies we can't license as open source into the browser as optional NPAPI plugins with different licensing.

All that said, it is becoming a huge maintenance burden, particularly on Linux, and it doesn't seem to have a bright future for the reasons you stated.