Apparently Codex can port Pale Moon to GTK4...

[athenian200]

So, I recently got a Codex subscription, and also installed Fedora on bare metal because some of the stuff I was doing seemed to go beyond what virtual machine testing can do reliably. I did not have one at the time I did the Python 3 port, and what little AI use I did for that was just copying code snippets from Copilot manually. But this GTK4 port is 100% AI generated... I did not write a single line of code.

The main purpose of this was to see what Codex can do and whether what I was asking was too tall an order. It seems pretty superfluous if we can get a decent Qt6 port going, honestly, but here's what I managed to do:

Screenshot From 2026-06-15 02-05-17.png

So, it can now apparently use at least some custom themes, XUL extensions work, it has working sound and video, OMTC works reliably even if OpenGL doesn't. It can do basic text copy/paste, open multiple windows, and seems to look pretty pretty good for... well, being what it is.

It does, unfortunately, require hard-disabling NPAPI. But aside from that it seems like theming, XUL, and everything else is theoretically possible with GTK4. And it didn't require as much work as I thought. It turns out I don't need to write a custom replacement for libadwaita... most of the functionality we needed that was missing from GTK4 was either available through XDG portals or was moved into GDK, with XUL/Gecko itself able to compensate for the rest using native paradigms instead of falling back to GTK.

Codex did get a little overeager and try to add native DMABuf/VAAPI support for videos because it thought it could pull that off, but the result didn't look perfect (shadows were kind of crushed) so that was left behind an experimental flag. It also was hoping to move from Cairo to a native GL surface, but it hit a dead end there as well, so it still relies heavily on Cairo. Which makes sense given that the build flag to enable is still --enable-toolkit=gtk4-cairo, same as the other two. So this way it lives up to the name.

One odd thing I noticed when moving from software rendering to OMTC is that rapid scrolling resulted in weird vertical tearing that reminded me of an old TV that lost its vertical hold signal, until it chose to use explicit vsync. I'm wondering if that's evidence it's actually going through Wayland somehow, because I think that shouldn't happen on X11.

Anyway, if anyone wants to play with the code, it's here:

https://repo.palemoon.org/athenian200/U ... -dontmerge

It is definitely a little finnicky and it likely would not be hard to find bugs that crash the browser if you poke in odd little corners of the UI or really mess with it in ways I didn't think of during testing... but obviously this would need a lot of human review by me to fix up what the AI did, revert unneeded changes, and just apply a lot of common sense and research understanding everything it did before I'd feel comfortable actually using it. Unlike the developer-facing Python 3 side, though, I think this would likely need years of testing to be stable enough to be used seriously. UX stuff is so much harder to debug, honestly...

[Moonchild]

Hey that ain't bad at all! Glad you got it to work

obviously this would need a lot of human review by me to fix up what the AI did, revert unneeded changes, and just apply a lot of common sense and research understanding everything it did before I'd feel comfortable actually using it. Unlike the developer-facing Python 3 side, though, I think this would likely need years of testing to be stable enough to be used seriously.

I'm not sure it would need years, at all. It's not like this is touching the actual driver of the UI; it's interfacing code for which we already have similar structures for Codex to draw on. Typical that it was over-eager trying to do "modern application things" that are incompatible because that's been the most documented kind of transition but fundamentally incompatible with our code base.
I'd be happy to see this land after a thorough review by someone familiar with GTK other than yourself, as a build option, and call it "experimental" until the crinkles are ironed out.

[athenian200]

I'm not sure it would need years, at all. It's not like this is touching the actual driver of the UI; it's interfacing code for which we already have similar structures for Codex to draw on. Typical that it was over-eager trying to do "modern application things" that are incompatible because that's been the most documented kind of transition but fundamentally incompatible with our code base.
I'd be happy to see this land after a thorough review by someone familiar with GTK other than yourself, as a build option, and call it "experimental" until the crinkles are ironed out.

Yeah, the main thing I'd want to do before having anyone review it, though, is to at least organize it into a sane commit history and make it comprehensible, etc. See, I kind of have a process with this type of stuff... I generally do a "dirty" version as a proof of concept, where there are often large commits, no issue number, no real following of commit guidelines, and everything is left fairly rough. Then I go back, start over with a blank slate, and do a "clean" version manually using the "dirty" one as a reference, paying attention to keeping the commits small and reviewable, following commit guidelines to the letter, maybe catching bugs I missed, discarding debug prints, etc.

That's not mostly because this is AI though... that's just kind of how my process has always been. I did it with the SunOS, Python 3, pretty much everything that involved a ton of research and several commits. I don't know why it's so hard for me to plan commits out in a way I'm happy with initially, or why I can't mix creativity with structure well and have to do the exploration/prototyping separately from what I'd intend to hit the codebase, but that is the process I usually wind up with.

[Moonchild]

See, I kind of have a process with this type of stuff... I generally do a "dirty" version as a proof of concept, where there are often large commits, no issue number, no real following of commit guidelines, and everything is left fairly rough. Then I go back, start over with a blank slate, and do a "clean" version manually using the "dirty" one as a reference, paying attention to keeping the commits small and reviewable, following commit guidelines to the letter, maybe catching bugs I missed, discarding debug prints, etc.

That tends to be how I work too when making larger changes. Get a PoC first, then break it apart into chunks and scrutinize each chunk to get the logic broken down into something readable, then build formatted commits out of it. Being able to selectively stage hunks is a big help.

[UCyborg]

Is version control stuff something you get acquainted with in schools these days? Back when I was still a student, none of it was even mentioned.

So with bigger changes, are you supposed to make commits so small that intermediate versions don't even compile / work?

[Lootyhoof]

Good job!

If you could get it to draw in the titlebar (like current Firefox does) when tabs are on top, like how it is on Windows, that could be quite interesting from a theme perspective. Would also need the option to toggle the native titlebar in that case though.

[andyprough]

Had to overcome a few small build errors, but I've got it running now.

This seems a bit farther along than the Qt6 Basilisk build that we were looking at a few weeks ago. I did not have keyboard input on that build, and most things are working pretty well on this one. I've got keyboard input, streaming video, audio. Arrow keys don't work though. Copy/paste works for text, but image copy does not seem to be available. Mouse scroll wheel sometimes scrolls the screen up, sometimes down, seems a bit random. The context menus are a bit jumpy. I haven't seen any screen tearing yet. Error console works, web console works. Downloading files seems to work. I downloaded eMatrix and it worked to block a Cloudflare turnstile, so I'm guessing extensions work. Seems pretty good, I could almost feel like I could run this daily, although the missing arrow key function and the random scroll wheel results would end up being annoyances. But it kind of looks and feels stable and fine overall.

Here's some data:
My system - an MX 25.2 Fluxbox VM (I was using DWM if it matters)
Compiler: GCC, -O2, no LTO

Local fixes needed for build to succeed:
1. nsGNOMEShellService.cpp: replaced GdkColor/gdk_color_parse with GdkRGBA/gdk_rgba_parse.
2. Disabled updater because progressui_gtk.cpp still uses removed GTK3 APIs.
3. palemoon/components/build/moz.build: linked browser components against GTK/GLib libraries for GTK4.

[athenian200]

Had to overcome a few small build errors, but I've got it running now.

This seems a bit farther along than the Qt6 Basilisk build that we were looking at a few weeks ago. I did not have keyboard input on that build, and most things are working pretty well on this one. I've got keyboard input, streaming video, audio. Arrow keys don't work though. Copy/paste works for text, but image copy does not seem to be available. Mouse scroll wheel sometimes scrolls the screen up, sometimes down, seems a bit random. The context menus are a bit jumpy. I haven't seen any screen tearing yet. Error console works, web console works. Downloading files seems to work. I downloaded eMatrix and it worked to block a Cloudflare turnstile, so I'm guessing extensions work. Seems pretty good, I could almost feel like I could run this daily, although the missing arrow key function and the random scroll wheel results would end up being annoyances. But it kind of looks and feels stable and fine overall.

Here's some data:
My system - an MX 25.2 Fluxbox VM (I was using DWM if it matters)
Compiler: GCC, -O2, no LTO

Local fixes needed for build to succeed:
1. nsGNOMEShellService.cpp: replaced GdkColor/gdk_color_parse with GdkRGBA/gdk_rgba_parse.
2. Disabled updater because progressui_gtk.cpp still uses removed GTK3 APIs.
3. palemoon/components/build/moz.build: linked browser components against GTK/GLib libraries for GTK4.

That's not a bad result, given I only tested it on Fedora 43 under GNOME and hadn't tried anything else yet. That scroll wheel result is surprising, though, because the scroll wheel was working for me before. I think I had updater disabled anyway. I'm thinking that the changes you had to make may have been from this part I forgot to mention:

https://repo.palemoon.org/athenian200/P ... e9a636fe47

But yeah, the bulk of the changes were in platform. I feel like I always forget about the application directory and focus on the platform... which can result in oversights like this. I'm kind of impressed you were able to figure out exactly what was missing and reproduce it without even seeing the application side I forgot to link, but I'm guessing it's easy if you know GTK well.

Hadn't tested arrow keys yet, just tested and found those weren't working. Curious about what kind of mouse scroll wheel you're testing... for me when I move the scroll wheel up, it goes up, and when I move it down, it goes down.

But yeah, there is a reason why I'm getting into AI coding now... I've been following what LLMs can do off and on for a while. Two years ago, I would have thought using AI to code was only marginally better than using a search engine and pasting code snippets from Stack Overflow or upstream Mozilla by hand the old-fashioned way and trying to tweak it until it works with our codebase. Now it seems like... it's hard to explain, but it's finding testing infrastructure that Mozilla left in mach that I didn't even know existed. It sometimes makes me feel like it's... acting like a very patient Mozilla developer that's having to tell me very basic, obvious things I don't think any of us knew about our own codebase to the point that it is hard not to feel embarrassed when it points them out, and makes me realize just how much of what we inherited we've been underutilizing.

It really does feel like it's a better programmer than me... granted, I admit, I wasn't really the type of person who could code something up from scratch without pulling in a ton of libraries, hours of research on existing codebases, and/or reviewing upsteam Mozilla and adapting something back with a few additions. But I feel like I am the type of person who should by all rights be little more than a junior developer tweaking other people's code and putting pieces together, and this is... somehow filling in enough missing pieces between my coding ability and my long-term/abstract thinking that I suddenly am feeling more like an architect... if that makes sense. I feel like it could turn power users into programmers like I was up until recently, programmers like me into something closer to a serious developer, and anyone already functional as a serious developer into... I can't even imagine.

[andyprough]

I'm kind of impressed you were able to figure out exactly what was missing and reproduce it without even seeing the application side I forgot to link, but I'm guessing it's easy if you know GTK well.

I was just running all the build errors through Codex, it was spitting out the fixes. Codex on the build side and Codex on the error fixing side, pretty good one-two punch by OpenAI. I also assumed that some of my build errors may have been package differences between your Fedora and my Debian Stable (MX 25), which differences can get pretty substantial. Also you were running Gnome, and I don't have Gnome installed.

[Basilisk-Dev]

GTK4

Not planning on dropping older GTK support if this gets merged are we? I don't plan to ever release a GTK4 version of Basilisk.

Cool use of AI though, glad it's spitting out usable code for you. Some of the more difficult parts of the QT6 port was AI-based too, although a lot of it was code I had worked on myself.

[Moonchild]

Not planning on dropping older GTK support if this gets merged are we? I don't plan to ever release a GTK4 version of Basilisk.

No, I see no reason to drop older GTK, at least not for a good while (not having a crystal ball I can't really rule it out in the more distant future, of course, but there at least needs to be a very good reason other than "newer version available")

[athenian200]

Not planning on dropping older GTK support if this gets merged are we? I don't plan to ever release a GTK4 version of Basilisk.

Cool use of AI though, glad it's spitting out usable code for you. Some of the more difficult parts of the QT6 port was AI-based too, although a lot of it was code I had worked on myself.

I don't think the timing of dropping older GTK support has to do with when GTK4 is added. I actually nearly stopped working on this when you told me you were working on Qt6 (I kind of had a feeling Qt6 might work better once you told me it was on the table or you thought it was feasible), but then started it back up when that whole incident happened between you and Drugwash. I figured it would be easier to continue with what I already had than to pick up where you left off, if it came down to it and you'd lost interest.

Now it seems like we have multiple options (which is good honestly). I think at some point we could wind up focusing on releasing builds using newer toolkits than GTK2 (maybe in say, 2030, who knows), but I don't think we'd have an incentive to remove the code.