Future of GTK2 and Pale Moon

[andyprough]

I am thinking about a recent discussion between @athenian200 and @Basilisk-Dev regarding the future of GTK2 in Pale Moon, that went as follows:

Off-topic:
I don't think we should drop GTK2 support or NPAPI even if Linux distros are dropping support for GTK2. More experienced users will always be able to compile their own GTK2 if they truly need the GTK2 UI or NPAPI plugins. Even then, when we inevitably in a few years have to switch to an RHEL9 based distro for builds, GTK2 is still available for that OS as well. Same with RHEL10.

It definitely does do things. I had to make a few small patches in UXP, but I am using a modified personal fork of the LightSpark Adobe Flash NPAPI plugin on LoongArch, an architecture which did not even exist until after NPAPI was deprecated. It does not require GTK 2 or 3 at all. It uses SDL2.

Off-topic:
You make good points, Basilisk-Dev. Yeah, we would definitely keep NPAPI on non-Linux regardless (I think that's a settled question), but the RHEL10 support for GTK2 was kind of my concern here since I don't think they have GTK2 in the official repos. I was originally thinking of decoupling GTK2 from NPAPI at some point so that people don't have to disable it entirely to build on non-GTK2 systems, but a few years ago it seemed like there was no reason to do that given that all extant Linux NPAPI plugins were built against GTK2 and there were fears of user confusion if they tried to build NPAPI without GTK2 and most plugins were broken. LightSpark does seem like a good argument in favor of keeping NPAPI around on Linux. Granted, a non-GTK2 NPAPI build would support very few plugins, but it would still support some, as the protocol itself doesn't require it. Overall, I don't necessarily want to remove GTK2 (it really wouldn't simplify our code much because the GTK2 stuff is mostly off in its own directories), but I would prefer to minimize our dependency on it as much as possible, and maybe move official support to a different emphasis at some point because I don't think it will be easily accessible forever.

I'm not a developer, but I spoke to a developer friend about this topic recently, and he gave me some advice. I'm wondering if this advice is worthwhile in this context at all? Here's what he said:

One question is this: does NPAPI require GTK2 specifically, or does it require X11/XEmbed-style embedding? GTK3 still has GtkSocket/GtkPlug, and the docs say they support embedding one process’s widget inside another using the XEmbed protocol. Those widgets are X11-only and only work on a GdkX11Display. If Pale Moon’s plugin-hosting dependency is really about XEmbed, then a GTK3 browser may still be able to support NPAPI on X11. That is an inference, but it is a plausible one from the GTK docs.

One way of proceeding might be:

1. Make GTK3 the default/mainline Linux build.
Keep the ordinary browser on the newer supported toolkit path, since Pale Moon already supports GTK3 builds.

2. Define NPAPI as a legacy feature.
If plugin hosting depends on GtkSocket/GtkPlug, then the real compatibility boundary is probably “X11 only,” not “GTK2 forever.”

3. If needed, isolate plugins into a separate helper/container process.
If the current NPAPI code is too entangled with GTK2 internals to move cleanly, then the least bad answer might be something like the following: GTK3 for the browser UI, plus a small legacy plugin host linked against a bundled/private GTK2 runtime. Keep the GTK2 radius small and contained.
Do not vendor GTK2 for the whole browser unless forced.
Shipping a private GTK2 stack for the entire browser means Pale Moon effectively becomes the maintainer of an EOL GUI stack for security fixes, distro integration issues, theme bugs, accessibility quirks, and loader conflicts. That is a bigger commitment than bundling just enough legacy runtime for a plugin host.

4. Consider delivering the legacy path as a separate build or support tier.
For example: normal GTK3 build for most users, and a “legacy NPAPI/X11 build” or “plugin companion package” for the shrinking set of users who still need NPAPI.

The best way forward may not be “vendor GTK2 forever,” but “minimize how much of Pale Moon still needs GTK2.” If they can get NPAPI working in the GTK3/X11 build, that is a win. If not, then confining GTK2 to a small plugin-side compatibility layer could be preferable over making the whole browser depend on an abandoned toolkit.

The first thing I would test is if the current NPAPI hosting code can be made to run in the GTK3 build under X11 with GtkSocket/GtkPlug. If that succeeds, the project may not need to ship vendor GTK2 at all for plugins.

Is any of that sensible? Or have you already considered these things and realized they would all fail? Just checking - I am one of those people that haven't used NPAPI plugins for many years, and have no need for them going forward. But I understand trying to help those that do rely on them.

[athenian200]

Is any of that sensible? Or have you already considered these things and realized they would all fail? Just checking - I am one of those people that haven't used NPAPI plugins for many years, and have no need for them going forward. But I understand trying to help those that do rely on them.

Yeah, this makes sense. I do appreciate the advice. It is good to know that GTK3 does still support some of the functions needed, and I would probably have to look into this to see what error messages we get on distros where GTK2 isn't available, it has been a while since I checked on all this, and a lot of my assumptions were based on Bugzilla research which really only tells me what Mozilla thought, but their knowledge of the API may not have been the best because they were thinking in practical terms about deprecating something at the most rational time, not about digging into the API to see if they could save it.

I believe we already have plugin-host as a separate process for GTK3, if I'm not mistaken, and that's why we can run GTK2 plugins on the GTK3 version of the browser at all. The real sticking point is potentially having to ship a GTK2 runtime at all if distros don't offer it in their repos... licensing issues basically force our hand there. I don't think we'd need much of GTK2 to make plugins work, but we are basically in the situation where we build plugin-host against GTK2 so that loading plugins with GTK2 symbols in them doesn't cause issues. That part we have taken care of. The issue is more that we're not comfortable shipping a GTK2 runtime with the browser because the licensing on that library is not fully MPL compatible. If the user can somehow get ahold of GTK2, the plugins should always work.

We've actually long hoped users would port themes over to GTK3 and improve the look/feel now that the toolkit isn't changing as rapidly as it was early on (it's become the new stable release since GTK4 came out, and MATE actually looks half-decent with GTK3 because they are deliberately trying to mimic GNOME 2), but really the reason GTK2 has lasted as long as it has... is because most users just don't want GTK3, theme authors seem unwilling or unable to fix their themes for GTK3 environments, and thus GTK2 has remained primary because it's what users keep choosing rather than because we as developers would rather they use it. This is actually one of the reason why I have been a little anxious about users picking Linux over Windows lately. Because deep down, I know the Linux version is not in the best state for modern Linux, and it means more users relying on the version of our code that we'd rather they didn't, especially if they get advised by other longtime Linux users on the board to "get the GTK2 version" because it's the "good version" that works better with themes, and thus reinforcing the whole problem of themes not getting updated to work with GTK3.

The issue is that on distros where GTK2 isn't in the repos, but plugin-host was compiled with it available, most plugins would simply not work, I think, though possibly some still would. If someone wanted to compile Pale Moon on such a distro, they would, as things stand, have to disable NPAPI or hunt down and install GTK2 development headers themselves in a place where UXP can find them, so plugin-host can be built.

Another added wrinkle is that the version of glibc some plugins were compiled against isn't compatible with the glibc on modern Linux distros anyway, so even if GTK2 is available, they might not work. I mean, the Pipelight suggestion isn't coming out of nowhere. That said, the new project Basilisk-Dev mentioned to create open-source NPAPI plugins that can do what the old proprietary ones did is the kind of thing Linux/FOSS is a bit stronger on, and they definitely deserve a lot of credit for that.

[andyprough]

We've actually long hoped users would port themes over to GTK3 and improve the look/feel now that the toolkit isn't changing as rapidly as it was early on (it's become the new stable release since GTK4 came out, and MATE actually looks half-decent with GTK3 because they are deliberately trying to mimic GNOME 2), but really the reason GTK2 has lasted as long as it has... is because most users just don't want GTK3, theme authors seem unwilling or unable to fix their themes for GTK3 environments, and thus GTK2 has remained primary because it's what users keep choosing rather than because we as developers would rather they use it. This is actually one of the reason why I have been a little anxious about users picking Linux over Windows lately. Because deep down, I know the Linux version is not in the best state for modern Linux, and it means more users relying on the version of our code that we'd rather they didn't, especially if they get advised by other longtime Linux users on the board to "get the GTK2 version" because it's the "good version" that works better with themes, and thus reinforcing the whole problem of themes not getting updated to work with GTK3.

Just like with the non-AVX versions of Pale Moon, you (as in "you developers") could push users that want GTK2 and NPAPI over to community offerings, and eventually remove the official GTK2 offerings. Just make sure the community builders have the support they need to keep building GTK2 versions, for a reasonably foreseeable future. That would seem like one option. Probably not popular initially, but if there's little other choice then users would have to adjust.

The way the Downloads page is organized right at this moment, it appears as though the GTK2 version is preferable as it is the first version listed over GTK3. A simple change would be to list GTK3 first, and to put a paranthetical note after GTK2 saying something like, "(GTK2 is no longer recommended, as the libraries are unmaintained and this version may ultimately need to be deprecated)". A simple reorganization of the Downloads page like that would probably flip a lot of users over to the GTK3 version.

Regarding themes, I'm not a theme user, but I downloaded several from the Pale Moon Themes page and they all seemed to install and work on my GTK3 version. If there are some that don't work, they could be put into a separate section, noting that they are for people running the "unrecommended GTK2 version of Pale Moon with its unmaintained GTK2 libraries that may ultimately need to be deprecated" - something like that.

[Basilisk-Dev]

A simple change would be to list GTK3 first, and to put a paranthetical note after GTK2 saying something like, "(GTK2 is no longer recommended, as the libraries are unmaintained and this version may ultimately need to be deprecated)". A simple reorganization of the Downloads page like that would probably flip a lot of users over to the GTK3 version.

I would just put GTK3 first and just say "GTK3 (Recommended)" and then "GTK2" second. Saying "it may ultimately need to be deprecated" will probably make a lot of existing users who specifically want GTK 2 support think we are saying we will eventually drop support completely when that isn't the intention.

[andyprough]

I would just put GTK3 first and just say "GTK3 (Recommended)" and then "GTK2" second. Saying "it may ultimately need to be deprecated" will probably make a lot of existing users who specifically want GTK 2 support think we are saying we will eventually drop support completely when that isn't the intention.

Might not be the intention, but from what @athenian200 is saying, it sounds like there may not be much choice. The GNU/Linux distros are already rapidly dropping (or planning to drop) their GTK2 libraries.

[Basilisk-Dev]

Might not be the intention, but from what @athenian200 is saying, it sounds like there may not be much choice. The GNU/Linux distros are already rapidly dropping (or planning to drop) their GTK2 libraries.

I'm really not interested in maintaining yet another one of the million forks of UXP, which is what I would do if UXP dropped GTK2 support. If the code still works we should keep it regardless and allow the community to support it on a best effort basis. Advanced users can compile their own copy of GTK2 as I stated earlier if they truly need GTK2 support and their distro doesn't provide it.

[athenian200]

Might not be the intention, but from what @athenian200 is saying, it sounds like there may not be much choice. The GNU/Linux distros are already rapidly dropping (or planning to drop) their GTK2 libraries.

Yeah, and of course we will keep providing a version that can work with GTK2 if they can find it (probably into the early 2030s at least), but users may find that they have to hunt down a copy of the library themselves (maybe an old RPM or a DEB if they can't compile it), since even if we can build against it, they still need the runtime. Hopefully if it gets to that point, more of them will shrug and download the GTK3 version, but the really scary thing is the double-whammy implied by this.

Let me put it like this. Pale Moon is a browser that prides itself on customizability and legacy options like NPAPI. We have no problems being that sort of browser on Windows or Mac. But on Linux... it feels like we're becoming something else. Just a worse Firefox that can't keep up with modern standards, and which just barely runs with no NPAPI and ugly themes. That's... not a good place to be, you get what I mean? Obviously I don't think it's entirely our fault, but people will start pushing us on how to build GTK2 so they can use the browser the way they want, or trying to build it themselves and frustrated they can't find it, etc.

This is not about dropping GTK2. At the moment, there's no pressing reason to remove the code, and no advantage in doing so. This is about having a version of the browser that works well for people who don't have access to GTK2, and not leaning on that old toolkit to have something worthwhile to offer people in that ecosystem. Linux is a different situation from XP, the XP code we wanted to get rid of was in the browser core. GTK2 is off by itself in the widget code, and it will remain relevant to people who stay on X11 if nothing else (which I imagine could be up to 30% of the Linux community). This actually resembles trying to keep up with rapidly changing web standards and falling short, but in our platform code, more than anything else.

Just to be clear so anyone reading this understands, It's not about us voluntarily dropping GTK2 and someone making a protest fork... it's about GTK2 being dropped from distros and Linux users beginning to pester us constantly asking where they can get GTK2 after that happens, and we'll be expected to help them build a copy or find an RPM, etc. And the type of users doing this... they aren't the type that should be building a UXP application, they're usually out of their depth but desperately clinging to something old because they want their old stuff to work and don't know any better, and if we stop providing a GTK2 version, they'll try to build it and then get mad at us because it wasn't easy to build. It's more a case of, we'll leave the code and keep building the binaries, but unless they're willing to fight to obtain a copy of that old library, it won't do them any good and they'll be on the version of our browser they don't like because it's "the only one that works" and resent us a bit for the state of it. Maybe some of them will stick with ancient Linux or enterprise editions, but a lot of them will just use a normal modern Linux distro and fight it tooth and nail while getting angry with us.

[andyprough]

This is not about dropping GTK2. At the moment, there's no pressing reason to remove the code, and no advantage in doing so.

Hopefully that addresses @Basilisk-Dev's concern about dropping GTK2 support from UXP itself. Sounds like that is not on the table, which is good news.

And the type of users doing this... they aren't the type that should be building a UXP application, they're usually out of their depth but desperately clinging to something old because they want their old stuff to work and don't know any better, and if we stop providing a GTK2 version, they'll try to build it and then get mad at us because it wasn't easy to build.

Which goes back promoting the GTK3 binary to the #1 GNU/Linux position on the Downloads page, and beginning to communicate something to the users so they know that this distros-dropping-support train is about to hit them right in the teeth in a very short period of time, and they need to start thinking about planning (or changing plans) accordingly.

From what you said earlier, it would appear that EVEN IF you shipped a GTK2 runtime with Pale Moon, it still probably wouldn't run with all plugins, and you would have various glibc mis-matches, etc. You apparently can't just fix people's problems by adding all the libraries to the official Pale Moon binaries.

[andyprough]

But on Linux... it feels like we're becoming something else. Just a worse Firefox that can't keep up with modern standards, and which just barely runs with no NPAPI and ugly themes. That's... not a good place to be, you get what I mean?

And just to clarify - Pale Moon has tremendous advantages on GNU/Linux desktops, including substantial advantages in resource usage and the ability to control resource usage. Also, recall that on many distros you obtain a program like Pale Moon by building it through use of a "recipe" or a "port" or a PKGBUILD, or you just manually build it because you have some optimizations you are building into it. When you have to build a browser, you REALLY want to be building Pale Moon or Basilisk, and not spending hours upon hours trying to build a chromium-based or Firefox-based browser only to have the build process crash. I can build Pale Moon on my current system in about 10 minutes, with reliable and workable results, which is just remarkable.

[athenian200]

Which goes back promoting the GTK3 binary to the #1 GNU/Linux position on the Downloads page, and beginning to communicate something to the users so they know that this distros-dropping-support train is about to hit them right in the teeth in a very short period of time, and they need to start thinking about planning (or changing plans) accordingly.

From what you said earlier, it would appear that EVEN IF you shipped a GTK2 runtime with Pale Moon, it still probably wouldn't run with all plugins, and you would have various glibc mis-matches, etc. You apparently can't just fix people's problems by adding all the libraries to the official Pale Moon binaries.

Yeah, I think you're right on that one. That sounds like the most practical approach. You are really making a lot of sense here.

And also, thanks for pointing out that we do still have a build-time advantage. I'm sure people understand we won't be figuring all this out right away... that Pale Moon will be in a rough state on Linux for a while. Just like it sometimes is due to Cloudflare and other things beyond our control. And it's not like we aren't making some progress, we did manage to get our Python 3 migration done. Which will help Linux users out a lot. It is one of the things I thought we needed to do for them, since a lot of them are self-building Pale Moon and struggling to find Python 2.

[mr tribute]

Regarding themes, I'm not a theme user, but I downloaded several from the Pale Moon Themes page and they all seemed to install and work on my GTK3 version. If there are some that don't work, they could be put into a separate section, noting that they are for people running the "unrecommended GTK2 version of Pale Moon with its unmaintained GTK2 libraries that may ultimately need to be deprecated" - something like that.

Agree. Also, I don’t think Pale Moon themes are that popular among Linux users. The whole idea is to have a gtk theme (gtk4/gtk3/gtk2) that gives a consistent look to every gtk application on your desktop.
Off the top of my head I can’t name a single application in Debian Stable that still uses gtk2. Maybe the LXDE environment.

Which goes back promoting the GTK3 binary to the #1 GNU/Linux position on the Downloads page, and beginning to communicate something to the users so they know that this distros-dropping-support train is about to hit them right in the teeth in a very short period of time, and they need to start thinking about planning (or changing plans) accordingly.

From what you said earlier, it would appear that EVEN IF you shipped a GTK2 runtime with Pale Moon, it still probably wouldn't run with all plugins, and you would have various glibc mis-matches, etc. You apparently can't just fix people's problems by adding all the libraries to the official Pale Moon binaries.

Stevo that builds Pale Moon for MX Linux (and antiX) has taken a sensible approach in my opinion.
In 2021 he built Pale Moon gtk2 for MX main repo and put Pale Moon gtk3 builds in MX test repo.
In 2023 he stopped doing Pale Moon gtk2 builds and put Pale Moon gtk3 builds in MX main repo. (No one complained about that).
When AVX builds were introduced by Pale Moon devs, Stevo continued to build Pale Moon SSE2 for MX main repo and put Pale Moon AVX builds in MX test repo. (No one complained about that).
Well, one forum member complained that official Pale Moon wouldn’t run and was advised to install from the MX repo instead. There were quite a lot of non-AVX CPUs produced even in recent years (mobile Intel Celeron).
Gtk2 was declared dead by Gnome in 2020. Compared to AVX, gtk2 seems like a non-event to me.

That being said the ability to build Pale Moon using Python3 seems to be a very positive development.

[Lucio Chiappetti]

Agree. Also, I don’t think Pale Moon themes are that popular among Linux users. The whole idea is to have a gtk theme (gtk4/gtk3/gtk2) that gives a consistent look to every gtk application on your desktop.

Well, personally as a Linux-only user (and an X11 user ... I hope not to be forced to move to wayland throughout my life) I do not use any desktop environment but a window manager (namely FVWM), which is very light and highly customizable (your way, your window manager ? ).
So I never explicitly used a gtk theme (I have also been told that theming GTK3 or above is not a trivial task)
I have also never used a browser theme ... but I won't mind using one (if gtk2 is dropped) which would give the look-and-feel of which I posted an image in thiis post https://forum.palemoon.org/viewtopic.ph ... 65#p272775.
Essentially what I'd like its to have only-text buttons (which is controlled by the Pale Moon preferences), with an Helvetica-like font over a plain gray background. This at the moment is achieved by this .gtkrc-2.0 (that's why I said explicitly above ... I guess this theming affects only Pale Moon)

Code: Select all

gtk-theme-name = "Traditional"
gtk-key-theme-name = "Emacs"
style "font"
{
font_name = "DejaVu Sans 12"
}
widget_class "*" style "font"
gtk-font-name = "DejaVu Sans 12"

Any recommendation for an existing Pale Moon theme which will give that look-and-feel ?

[Basilisk-Dev]

And the type of users doing this... they aren't the type that should be building a UXP application, they're usually out of their depth but desperately clinging to something old because they want their old stuff to work and don't know any better

Seems like a very hypocritical viewpoint to me. If you were to ask someone from Mozilla why forks like Pale Moon exist, pretty sure they would say this exact same wording verbatim. It's not up for us to tell users that we know better than them. We don't know what their needs are or why they have those needs. They have reasons to want these older tookits, just like we have reasons to stick with browsers that support XUL/NPAPI instead of WebExtensions.

[athenian200]

Seems like a very hypocritical viewpoint to me. If you were to ask someone from Mozilla why forks like Pale Moon exist, pretty sure they would say this exact same wording verbatim. It's not up for us to tell users that we know better than them. We don't know what their needs are or why they have those needs. They have reasons to want these older tookits, just like we have reasons to stick with browsers that support XUL/NPAPI instead of WebExtensions.

To clarify, what I meant was that they don't have the skills to build a UXP application, not that I'm making a moral judgment on whether they "should" build anything or not. Poor choice of words on my part. I meant that the people who are most attached to GTK2 are often not the most tech-savvy and the most likely to react badly to seeing a pixel or two out of place. And I'm sorry, I'm going to push back and say, in this case we know EXACTLY why they need GTK2 (we have years of user complaints to go on)... and it's either because they want their themes to look exactly right, because they've gone unmaintained... or it's because they use an NPAPI extension that was compiled against GTK2. I know one user was openly telling me he uses it because he's pissed about the way GTK3 handles spillover menus with a large font and expects us to support GTK2 forever because he thinks the new way "looks ugly." So yes, I am whining a bit about picky users who aren't the brightest complaining about every pixel they see out of place and holding up GTK2 as the answer and cheering it on, not realizing what that means for the developers or what position they are putting us into by making that their "solution."

I'll tell you why I don't see this as hypocrisy, but I don't know if you'll get it. The difference is that NPAPI and XUL are part of our project and still actively maintained. But the price of keeping those developed and actively maintained, in my opinion, should be that we move them to a newer base and keep them alive as more than museum pieces, otherwise we are not much better than people using old binaries of FF52. My philosophy, and I am not saying you have to share it or that anyone else on the project shares it, is that we are about taking older technologies like XUL and NPAPI into the future, not keeping the past preserved in amber forever. Furthermore, if you look at my past, you'll see I have never shipped Epyrus with GTK2, always told people who want that to build it themselves, and actually did the Python 3 port in part so people who do self-build Epyrus would have an easier time, so I am if anything being consistent here.

I mean, and how far do you want to take this? What if someone only has a computer with GCC 7 installed? Should we support GCC 7 forever? We used to be compatible with that, too. Maybe porting to Python 3 wasn't the right call and we should have stuck to Python 2 because we are an "old stuff" project and should be dependent on and compatible with the oldest things even if it causes inconveniences on modern Linux? I was always afraid that was the mentality of people around here, and frankly... I didn't sign up for this thinking we were curating a museum. I never got the impression that was MC's goal here, even if some of our users kinda wish it was. I mean... the only difference between GTK2 and those other things, is that GTK2 just unfortunately happens to be user facing and thus people have an aesthetic preference for how it looks, which I guess in your mind and that of others, means using it less and trying to steer away from it is some kind of betrayal. But... in my mind, GTK2 is a tool, just like Python or GCC. We use it to be compatible with Linux. We don't use it on Windows or Mac. If modern Linux isn't very compatible with it anymore... then obviously it's not doing its job.

Now, does that mean we can't have a GTK2 build targeted to older Linux, or other Unix-like systems that still ship it? Of course it doesn't, we will likely do that, just like on Mac we support PowerPC even though that's obviously not the primary Mac platform anymore. But I think at some point we need to acknowledge that's what it is rather than pretending it's still relevant to any modern system and letting people keep the false notion that modern Linux gives them a choice (without regard to the few people who will somehow get it working by hacking around and inspire others to go down rabbit holes and get mad at us when they get confused because it's "not easy"). Please note my exasperation with how users behave around these deprecations and how the expectations of the users make our lives harder and they start making annoying demands or complaints even though the situation is mostly not our fault, as hypocritical and annoying as you may find my viewpoint.

If I'm being honest, I'm a bit sad that I'm having to have this disagreement with you, and that it's become this heated. You are a developer too, I would think you'd "get it" at least a little.

[Basilisk-Dev]

If I'm being honest, I'm a bit sad that I'm having to have this disagreement with you, and that it's become this heated. You are a developer too, I would think you'd "get it" at least a little.

Sorry if you interpreted things as being heated. I was enjoying the discussion and think debate is healthy. I'm not upset or angry with you in any way.

[athenian200]

Sorry if you interpreted things as being heated. I was enjoying the discussion and think debate is healthy. I'm not upset or angry with you in any way.

Yeah, no worries then. I was worried you were upset because you said "hypocritical," but otherwise I'm actually enjoying the discussion too.

It can be hard to interpret tone over text, so no hard feelings. I've gotten into much worse misunderstandings before, it's all good.

[Moonchild]

I didn't sign up for this thinking we were curating a museum. I never got the impression that was MC's goal here, even if some of our users kinda wish it was.

Let me be very clear on this:

No.

This project was never about curating a museum or preserving things in their exact state the way they were 15 years ago. Quite the opposite. I did make concessions to the user base not moving forward a few times when I really wanted to, personally, but that is not and has never been the underlying vision for the project. Did that mean Pale Moon and the platform weren't exactly shaping up to what I wanted? Absolutely. But that was a compromise that was necessary if I didn't just want to build something "just for myself and others can take it or leave it" (like a good number of Linux distros seem to be). So, some users got some of what they wished for, and I got some of what I wished for.
Regardless, Pale Moon and UXP are supposed to develop, to be maintained, and to be modernized as time goes on. The GTK2 issue is a problem, but at the same time I've also kind of let the Linux portion of our community guide itself in that respect. You can either come to a satisfactory solution, or you don't. As I indicated elsewhere though, I don't think it's feasible (or sane) to start vendoring a whole graphics subsystem with the browser, and so my answer to bundling gtk2 libs with the browser will just have to be a solid "no thanks".
It's going to be a pity if NPAPI on linux will be dropped because of decisions by distro maintainers to remove GTK2 and making it hard to obtain; but the reality is that the plugins people want to be running are old and don't have GTK3 versions. It simply goes out of scope for us.

If you want to run a nostalgic browser, you can always run an old and unmaintained version of whatever you prefer for using it with local plugins as well. But you have to start treating it as a purpose-built application just for that task and not a general-use web browser to be used for the Internet. You'll have to specialize.

There are also essential differences between GTK and XP support and e.g. a processor architecture. You can't even compare them in how they hook into the platform. There are massive differences in scope. So, be carefuly trying to compare them when you're discussing things here because you're likely comparing apples and kitchen sinks.

[andyprough]

I looked up the GTK2 drop timelines for the various major distros last night - Fedora has already killed it, Arch is killing it right now as fast as it can and has moved their GTK2 packages out of the main repos and into the AUR, Debian will not ship it in about 16 months with Debian 14, and is likely to cut it from Debian Testing before that, and Ubuntu will not ship it with 28.04 in 2028, and will probably have to drop GTK2 before then if Debian Testing drops it sooner.

The good news is that unless your users are on Fedora (which should be very few users) or Debian then they could potentially use GTK2 support from the Arch AUR or Ubuntu LTS for a few years. And those Ubuntu LTS's do have extended long-term support for up to 15 years of security updates to core packages with a free Ubuntu Pro account. If people want to keep using GTK2 versions of Pale Moon with NPAPI support, a good idea would be to do what I do and keep a VM of a workable version of Ubuntu LTS and sign up for the free Ubuntu Pro extended LTS subscription, and ride that out for a good long while. I think my Ubuntu 18.04 LTS vm is still good to use until about 2032, and a new Ubuntu 26.04 LTS vm today would be supported by Canonical until around 2040. So there's some relatively easy options for people who still want to be using their flash player plugin 5 years from now.

Not quite as dire as I was thinking.

[athenian200]

It's going to be a pity if NPAPI on linux will be dropped because of decisions by distro maintainers to remove GTK2 and making it hard to obtain; but the reality is that the plugins people want to be running are old and don't have GTK3 versions. It simply goes out of scope for us.

I agree for the most part, but one thing I am interested in trying to facilitate (and if it fails, we may well have to drop NPAPI on Linux some day) is possibly finding a solution to using NPAPI on Linux that doesn't involve GTK2. Another awkward thing is that if I'm not mistaken, we do currently still depend on NPAPI and GTK2 to build WebRTC, which is a problem for Basilisk (I had almost forgotten but just remembered). So really I am leaning towards keeping the code in (I don't think it really gets in the way because it's all in the widget/gtk directory), but telling people they are on their own with it at some point and that it's not an officially supported configuration. Like andyprough said in his OP, there are some people that think it may be possible get our NPAPI subsystem to work around the incompatibilities between GTK2 and GTK3 easily enough that we can keep it without GTK2, and that Mozilla just didn't go down that rabbit hole to find out because they were planning to deprecate it anyway. But yeah, I pretty much agree continuing to rely on GTK2 is a no-go.

Essentially, the compromise I've been considering with people who still want GTK2 is leaving the code around as an option for self-builders. That's... kind of what I did with Epyrus, and what I've been trying to foreshadow with that decision for a while. I kind of wanted people who like GTK2 to understand that if they want it and think they are adult enough to make their own choices, they have to be tech-savvy enough to build Epyrus themselves, and either pick out a distro that has it, find an RPM packaged by someone else for their preferred distro, or maybe even one day build GTK2 themselves. Basically sort of a nudge towards "If you are on Linux and you want someone to hold your hand, you need to use something better supported. If you want it your way, you will have to build yourself and prove you understand exactly what you're choosing and how to sustain it." That way, we don't have to deal with GTK2 protest forks like a full-on removal would trigger, but also aren't under as much pressure to support GTK2 properly ourselves in the face of an increasingly hostile ecosystem. People who would otherwise make protest forks might submit occasional patches if we're lucky, and if they submit patches for that, they might submit them for other things eventually. I see it as the easiest middle-ground option.

I'm not necessarily against power users who want to use old enterprise distros, custom RPMs, or a self-built GTK2 to get exactly what they want. Those are the kind of GTK2 users that, in my view, are not a problem. I'm mostly uneasy about confused users who aren't that tech-savvy and don't like to see a pixel out of place expecting things to be easy and polished, and having expectations because of how easy GTK2 was to handle in the past and how it "solved" various display issues on Linux. I'm willing to bet more people are using GTK2 for the aesthetics than for NPAPI, honestly.

[Mæstro]

It means a lot to know that you are working on preparing in advance for GTK2’s depreciation by most Linux distributions. I appreciate the early warning. Since i know some users here like MX and Antix, I would be curious to whether those distros intend to uphold it. Some casual searching also suggests to me that the problem might not be as severe as expected: Firefox 64 supported Flash using GTK3. Naïvely, and you could correct me if your expertise makes it obvious I am making a basic error here, this suggests that support can be preserved. Has anybody tested NPAPI in Pale Moon on current Fedora and an otherwise compatible system to tell us whether it fails?

Debian will not ship [GTK2] in about 16 months with Debian 14…

If Ubuntu’s LTS are to be counted, one should also note that Debian 13 is expected to enjoy such support until 2035. In any case, I should take this as an early warning. I have been prepared for the possibility of Flash failing in Linux sometime in or after 2029 for me. If this were to happen, I should simply move my Flash browsing into my XP virtual machine which uses Roy Tam’s builds, as I have exhibited a few times before. I could also consider options like running the Windows version of Pale Moon in Wine.

I kind of wanted people who like GTK2 to understand that if they want it and think they are adult enough to make their own choices, they have to be tech-savvy enough to build Epyrus themselves, and either pick out a distro that has it, find an RPM packaged by someone else for their preferred distro, or maybe even one day build GTK2 themselves. Basically sort of a nudge towards "If you are on Linux and you want someone to hold your hand, you need to use something better supported. If you want it your way, you will have to build yourself and prove you understand exactly what you're choosing and how to sustain it."

I kindly caution against this approach, simply because I fall in the unhappy, neutral ground between the two classes you discuss. Because I know you are also autistic, I can speak forthrightly: The kind of involved, often unpredictable technical work which building software (or much troubleshooting) involves is the kind which tends to provoke panic attacks in me. Although I do not imagine I would be personally affected by your decision here, it is easy for me to conceive of somebody else like me in this respect. In our case, being a responsible adult means recognising we need to protect our emotional health against hazards like those uncoöperative IT can provoke.

In any case, I believe that outright depreciating NPAPI for Linux, even if it is due to underlying GTK2 changes beyond your scope, would be unwise because of the inevitable backlash. It would be far too easy for someone naïve or malicious (and you know there are many of these out there) to portray Pale Moon as reneging on its promise to preserve NPAPI support, even if this is no more in your hands than Flash’s incompatibility with younger Glibc versions if run with Nvidia hardware. Better in the worst case, I think, to keep nominal NPAPI support with the proviso for the user that most distros have torn the ground out from under his feet.