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.

[kjpod]

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?

I have no Idea how possible to cross port NPAPI code (I am not a "real" programmer)
so why am I interrupting is because PDF plug-ins of that era included SumatraPDF which has windows x86/64 plug-in ability that still works with daily updates in Basilisk and Pale Moon and Kameleon
It now has an ARM variant HOWEVER I have no idea if the source code for Windows.dll is portable to ARM
apparently SumatraPDF is reasonable in Linux Wine but never heard if that worked with Linux Browsers with or without Wine interface

[jb_wisemo]

Just 2 more data points:

1. There is (or was) a generic Linux NPAPI plugin that could wrap every external program / protocol handler listed in the Linux MIME configuration. This covered PDF and any other file format that had an installed viewer, and could probably be told to also wrap protocol handlers such as telnet and ssh . This was open source and available for most/all architectures that had an XFree86 port .

2. I happen to co-maintain an NPAPI plugin (still only 32 bit x86 for Windows) that provides the client/viewer for a remote screen/desktop protocol. The plugin is currently Win32 only because it was originally created in the early 2000s as the Firefox/Netscape port of an IE plugin that doubled as a "custom control" for higher level languages . This task is the reason I started using Pale Moon at all .

[moonbat]

I have no Idea how possible to cross port NPAPI code

It needs to be built separately for each platform and architecture that it's meant to support. So these days it's Windows/Mac/Linux and 32 or 64 bit, so it would need 6 separate binaries to cover all platforms in current use (Assuming there is or was a 32bit version of Mac OS in use today)

[UCyborg]

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.

But then you get the same old PDF.js or you reinvent your own in JavaScript (yikes!). Some ancient version of it already exists as extension that works in UXP browsers and SeaMonkey. But with NPAPI you can get something like PDF-XChange Editor in the browser.

[Basilisk-Dev]

There is (or was) a generic Linux NPAPI plugin that could wrap every external program / protocol handler listed in the Linux MIME configuration. This covered PDF and any other file format that had an installed viewer, and could probably be told to also wrap protocol handlers such as telnet and ssh . This was open source and available for most/all architectures that had an XFree86 port .

Can you provide a link or more info?

So these days it's Windows/Mac/Linux and 32 or 64 bit, so it would need 6 separate binaries to cover all platforms in current use (Assuming there is or was a 32bit version of Mac OS in use today)

For MacOS you'd want 64-bit x86 and 64-bit ARM.

[Kruppt]

Can you provide a link or more info?

I think he is referring to mozplugger:
https://github.com/unix-junkie/mozplugger

[jb_wisemo]

Can you provide a link or more info?

I think he is referring to mozplugger:
https://github.com/unix-junkie/mozplugger

Bingo!