{
"$type": "site.standard.document",
"bskyPostRef": {
"cid": "bafyreidpkjyey3vibba4ik2konyn5gfnsujyacp5ofmckdbofnkcypljwa",
"uri": "at://did:plc:hqad6xwuzg7oqfmwylfkvqfm/app.bsky.feed.post/3mohsxsrc4ox2"
},
"path": "/viewtopic.php?t=33537&p=275703#p275703",
"publishedAt": "2026-06-17T01:21:38.000Z",
"site": "http://forum.palemoon.org",
"textContent": "> Thinking about adding a separate build-time config option for something like --disable-npapi-gtk.\n>\n> The intent here is to separate the NPAPI code in our tree from the GTK supporting code for NPAPI plugins. The idea is that users can continue to run Xlib based NPAPI plugins on Linux distributions where GTK2 is no longer shipped.\n>\n> The pref would be enabled by default so --enable-npapi would build with the GTK2 NPAPI support by default. The user would have to manually pass in --disable-npapi-gtk in mozconfig if they want it disabled.\n>\n> Thoughts? Is this something we want? I have several hours of free time over the next few days so I'll try to implement this if people are interested.\n\nThat's actually something I already kinda tried to do but didn't have much success with. I got Java working that way (recently re-confirmed that Java is absolutely fine with pure Xlib/XEmbed), but wasn't able to find anything else that was compatible, though to be fair I'm thinking the other ones that work without GTK2 might be so old that they would only work with a 32-bit Linux version, which I didn't think was worth testing since that's not an officially shipped configuration anyway.\n\nSo my advice to you if you pursue it, is absolutely start with Java NPAPI plugin support as a sanity check, and then try to see what you can get working from there, probably stuff like Lightspark or other open source NPAPI plugins you can rip GTK2 assumptions out of.\n\nI did actually test my previous option thoroughly enough that I believe we can build a GTK2 version with no NPAPI, if for some reason anyone wants one. I actually made sure that build flag works on most platforms, just in case NPAPI itself ever becomes a liability due to something like, say, computing moving away from x86-64 and all the new architectures having basically no past library of old plugins.\n\n* * *",
"title": "Platform Development • Re: Thoughts on splitting out --enable-npapi and gtk?",
"updatedAt": "2026-06-17T01:21:38.000Z"
}