Contributed 3rd Party Builds • Re: 32bit and gtk2 builds for Debian/Bookworm

Why?

Essentially, every NPAPI plugin ever created for Linux was compiled against GTK2 (aside from some much older ones compiled against Motif). If we remove the GTK2 requirement for NPAPI on Linux, then plugins behave unpredictably:

1. They may crash the browser if they were compiled against GTK2 and the browser does not have GTK2 symbols available for it to hook into.

2. The plugin may fallback to Xlib or Motif (not ideal).

3. The plugin may just silently fail without telling users why.

4. The plugin may work, if it has no GUI and no user-facing controls, and thus wasn't compiled against GTK2, but this would be fairly rare.

We seem to safely handle the case where the browser's plugin component was built with GTK2 symbols available, but the system doesn't have it. In that case, plugins just reliably fail to work but in a way that doesn't crash anything, I think.

That's why I reluctantly implemented MOZ_DISABLE_NPAPI as an option a few years ago. People are already using it to build the browser on GTK3-only systems where GTK2 isn't available. The other thing that's worth mentioning is... on non-x86 architectures, especially newer ones, plugin support doesn't really do anything because NPAPI plugins were never built for those platforms to begin with.

About the only way I can think of to "save" NPAPI on Linux is to use something like the old Pipelight project with Wine somehow to run the Windows version of the plugin on the Linux version of Pale Moon, and at that point you might just as well use the Windows version of Pale Moon in Wine (a configuration we don't officially support, by the way). There are a few projects that create their own NPAPI plugins that don't link against GTK2, and that might be another path forward, but it would require us adopting the exact same mentality with regard to NPAPI that we do with XUL extensions... that if it's not updated and maintained, you can't expect it to work, and I don't think that would go over well. Plus it would potentially confuse users of Windows where the old plugins would continue to work as normal, and they wouldn't see the need to stick with maintained NPAPI plugins over official versions. When people think NPAPI, they think of popular plugins that haven't been updated in years and will expect them to work if we claim support.

But anyway, my suggestion if you want to keep NPAPI on Linux is to revive and fork Pipelight, get it working with Pale Moon and some version of Wine, package it up so people can use it, and if needed submit patches so we can use that. Then, we can keep Linux NPAPI support in some form. But seriously, Linux NPAPI support is one of the forces keeping the GTK2 albatross tied around our necks. A lot of Linux users also prefer the way it looks aesthetically with some themes and will not be happy if it's dropped in favor of GTK3, especially given how GTK3 looks in our tree. Linux is a very frustrating platform with regards to how often APIs change and backwards incompatibilities combined with viral GPL licensing making maintaining older stuff untenable. Although I personally think it's not worth even considering dropping GTK2 unless we find something better than GTK3 to replace it with (GTK3 is already getting kind of old at this point). People don't like that version of the browser, and sometimes it really feels like the Windows version is moving forward while the Linux version is still stuck in 2017 with Firefox 52...