Open Bug 1701123 (gtk4) Opened 4 years ago Updated 26 days ago

Port Firefox to GTK4

Categories

(Core :: Widget: Gtk, enhancement, P5)

Product:
Core
Component:
Widget: Gtk
Type:
enhancement

Tracking

()

People

(Reporter: malix0, Unassigned)

References

(Depends on 1 open bug, Blocks 3 open bugs,
URL
)

Details

Attachments

(8 files)

basic-config.patch
1.09 KB, patch
Details | Diff | Splinter Review
gtk4-config.patch
3.96 KB, patch
Details | Diff | Splinter Review
gtk4-config-v2.patch
4.37 KB, patch
Details | Diff | Splinter Review
gdkrgba.patch
831 bytes, patch
Details | Diff | Splinter Review
icon-decoder.patch
2.99 KB, patch
Details | Diff | Splinter Review
fxgtk4first.jpg
326.09 KB, image/jpeg
Details
fxgtk4fixedsize.jpg
395.87 KB, image/jpeg
Details
fxmenu.jpg
36.54 KB, image/jpeg
Details

User Agent: Mozilla/5.0 (Android 11; Mobile; rv:87.0) Gecko/87.0 Firefox/87.0

Steps to reproduce:

Now that GTK4 is officially released and also Gnome 40 is out. Is there a plan to port Firefox to GTK4?

Component: Untriaged → Widget: Gtk
Product: Firefox → Core

FWIW this involves killing basically all the native widget drawing code, since that's not allowed in GTK 4.

Status: UNCONFIRMED → NEW
Ever confirmed: true

This also means a binary backwards compatibility break. I don't think this is going to happen any time in the next few years. Of course, there's the possibility of allowing to build with Gtk+ 4 downstream, but as far as Firefox, as shipped by Mozilla, this is not going to happen any time soon even if the code is there (which it isn't).

LibreOffice is going on Gtk4+ porting. I don't know if they have tools that can help / automate the achievement.

https://cgit.freedesktop.org/libreoffice/core/log/?qt=grep&q=gtk4

(In reply to Massimo Fidanza from comment #4)

LibreOffice is going on Gtk4+ porting. I don't know if they have tools that can help / automate the achievement.

https://cgit.freedesktop.org/libreoffice/core/log/?qt=grep&q=gtk4

Is mentioned before there's no gain to port Firefox to Gtk 4.0 - it does not have any benefit but adds more problems.

(In reply to Martin StrΓ‘nskΓ½ [:stransky] (ni? me) from comment #5)

(In reply to Massimo Fidanza from comment #4)

LibreOffice is going on Gtk4+ porting. I don't know if they have tools that can help / automate the achievement.

https://cgit.freedesktop.org/libreoffice/core/log/?qt=grep&q=gtk4

Is mentioned before there's no gain to port Firefox to Gtk 4.0 - it does not have any benefit but adds more problems.

One of the major advantages would be to have thumbnails in the file chooser window which currently it does not have. Almost every user is using file chooser. That would be a good basic feature to have. https://www.reddit.com/r/gnome/comments/om8r4k/gtk_file_chooser_thumbnail_icon_view_update/

It likely could be archived by just using xdg-desktop-portal-gtk(widget.use-xdg-desktop-portal in about:config, AFAIU it's not a default).

Martin is right! No need to port to Gtk4. It only adds further entanglement with libadwaita, crippled theming, and a crippled X11 interface as they push wayland. There is no longer an expectation that Gtk will be responsive to developer needs outside the development of Gnome. This will likely pose increased problems/challenges for the future, so it may be time to start thinking about alternative toolkits.

David Rankin: Please don't add FUD and random incorrect statements to tickets - thanks!

If anyone is willing to work on it I can provide guidance/help but I don't have time to work on that. Please NI me in such case.

Chromium loads GTK at runtime, you can choose between GTK3 and GTK4:
https://chromium-review.googlesource.com/c/chromium/src/+/3062001

And it seems, they will add Qt:
https://chromium-review.googlesource.com/c/chromium/src/+/3583242

(In reply to peter.eszlari from comment #11)

Chromium loads GTK at runtime, you can choose between GTK3 and GTK4:
https://chromium-review.googlesource.com/c/chromium/src/+/3062001

And it seems, they will add Qt:
https://chromium-review.googlesource.com/c/chromium/src/+/3583242

Yes, that may be possible. Again any contribution is welcome.

(In reply to Martin StrΓ‘nskΓ½ [:stransky] (ni? me) from comment #12)

(In reply to peter.eszlari from comment #11)

Chromium loads GTK at runtime, you can choose between GTK3 and GTK4:
https://chromium-review.googlesource.com/c/chromium/src/+/3062001

And it seems, they will add Qt:
https://chromium-review.googlesource.com/c/chromium/src/+/3583242

Yes, that may be possible. Again any contribution is welcome.

Would it make sense, to open an new bug for this?

(In reply to peter.eszlari from comment #13)

Would it make sense, to open an new bug for this?

I does not matter, we need working patches / WIP builds first.

Someone mentioned above that "there is no benefit to using GTK4", so I'd like to point out this bug:-

https://gitlab.gnome.org/GNOME/gtk/-/issues/1895

This means that when using Wayland, the middle click function on the title bar to lower a window /does not work/ for applications using GTK3 and older.... I'm not sure how many people use this feature, but it's certainly something that I use all the time, and would very much like for firefox not to be the one app where that does not work.

While porting Firefox's whole widgetry from GTK3 to GTK4 is certaintly a big task, I'm wondering if enabling the file chooser portals (in bug #1658011) could allow Firefox to benefit from GTK 4.10's vastly improved FileChooser widget (compared to GTK3's), as a partial stopgap solution? The new GTK 4.10 FileChooser widget that now has a grid view mode with thumbnails is a major compelling advantage of GTK4 over GTK3 already, but maybe we can "cheat" and get that feature faster than a full GTK4 port...

(In reply to Jeff Fortin from comment #16)

While porting Firefox's whole widgetry from GTK3 to GTK4 is certaintly a big task, I'm wondering if enabling the file chooser portals (in bug #1658011) could allow Firefox to benefit from GTK 4.10's vastly improved FileChooser widget (compared to GTK3's), as a partial stopgap solution? The new GTK 4.10 FileChooser widget that now has a grid view mode with thumbnails is a major compelling advantage of GTK4 over GTK3 already, but maybe we can "cheat" and get that feature faster than a full GTK4 port...

See my reply here: https://bugzilla.mozilla.org/show_bug.cgi?id=1658011#c9

Please don't post the same question multiple times within 5 minutes, it just adds noise .

I've noticed GTK developers have given strong pushback against porting Firefox to GTK4 (particularly some months back on reddit here, but elsewhere too) and have generally recommended talking to the wayland client directly, using xdg-portals and other abstractions instead of a toolkit (similar to Windows/Mac).

I can see the logic in this - Firefox uses its own CSD, so GTK is mostly acting as a heavy wrapper. I wonder what people's thoughts are?

@miranda: The main issue with using a wayland client directly (plus xdg-portals) is that wayland is basically Linux-only right now (and FreeBSD, which basically implements a bunch of Linux APIs), so Firefox still needs to keep the Xorg abstraction around for all other platforms.

On top of that, xdg-desktop-portal and friends are also Linux-only, and even on Linux there's plenty of scenarios where they might not be an option. Firefox still needs things like file-pickers in all those scenarios.

Perhaps something simpler than GTK that provides ONLY those components would be the best fit, but, for the moment, GTK seems to be the only choice. Maybe if toolkits like iced had a filechooser they would be an option, but I don't know of anything that's a better fit right now.

Is there an issue open for porting to Qt? I realize how drastic of a change that would be, but GTK4 just doesn't seem compatible. Additionally, considering how friendly Qt (especially QML) is to CSD like Firefox's (and of course how it is by default cross-platform, unlike GTK) it doesn't seem to me on the surface like a terrible idea. It would even integrate by default with the themes of the host OS, thereby reducing how much Firefox has to style itself by default whilst allowing superior theme versatility to GTK4 by far.

I agree that interacting directly with Wayland and X would be a bad idea. The less to manage, the better, generally. I expect that Firefox's Linux support would only deteriorate if the developers were to write all of that code themselves rather than delegate it to an underlying toolkit.

The Qt Company have demonstrated poor behaviour as stewards of that toolkit with regard to open source releases, for instance recently making 5.x updates commercial-only, with little notice and before 6.x achieved feature parity, see:

https://www.phoronix.com/news/Qt-5.15-LTS-Commercial-Phase
https://www.theregister.com/2021/01/05/qt_lts_goes_commercial_only/

Qt might be shiny, but porting Firefox would put it at risk of the whims of the commercial decisions of The Qt Company (or a future owner).

(In reply to moz-nuc from comment #21)

The Qt Company have demonstrated poor behaviour as stewards of that toolkit with regard to open source releases, for instance recently making 5.x updates commercial-only, with little notice and before 6.x achieved feature parity, see:

https://www.phoronix.com/news/Qt-5.15-LTS-Commercial-Phase
https://www.theregister.com/2021/01/05/qt_lts_goes_commercial_only/

Qt might be shiny, but porting Firefox would put it at risk of the whims of the commercial decisions of The Qt Company (or a future owner).

https://kde.org/community/whatiskde/kdefreeqtfoundation/ surely prevents that.

But again, I think this should be discussed in a new issue, because isn't this somewhat off-topic? Ideally, a large meta-issue for deciding what to do now that GTK4 has been released with too-basic theming support is probably best for exploring what to do, with this issue included as dependent upon it.

I suggest you open a separate issue to discuss potentially using another toolkit for Linux. There seems to be some interest, and it's definitely a discussion worth having (and lots of exploration to be done). But let's keep it out of this and avoid spamming others following the on-topic discussion here.

(In reply to miranda from comment #18)

I've noticed GTK developers have given strong pushback against porting Firefox to GTK4 (particularly some months back on reddit here, but elsewhere too) and have generally recommended talking to the wayland client directly, using xdg-portals and other abstractions instead of a toolkit (similar to Windows/Mac).

One of those people would be me.

My main reasoning is that GTK is not a windowing platform, and Firefox code these days is targeting a windowing platform more than a toolkit. So thre is a mismatch between the API Firefox wants (like low-level input event access or tight control over the graphics framework) and the API a toolkit provides (widgets). On top of that, integration is not that big of a topic as it was 10 or 20 years ago, browsers do not follow platform interface guidelines as tightly and instead aim to provide a consistent web platform.

That's why my suggestion has been to consider moving to a Wayland-native layer and keep using the GTK3 layer for X11. Once such an effort is underway, it'd be possible to figure out how feasible it is to completely replace GTK usage with Wayland-native.

(In reply to Hugo Osvaldo Barrera from comment #23)

I suggest you open a separate issue to discuss potentially using another toolkit for Linux. There seems to be some interest, and it's definitely a discussion worth having (and lots of exploration to be done). But let's keep it out of this and avoid spamming others following the on-topic discussion here.

Yeah. Done – https://bugzilla.mozilla.org/show_bug.cgi?id=1827232. However, I obviously don't have the authority to add related issues, so for anyone with some actual authority viewing this issue, do with the issue what you will. I realize I'm not the best person to be the issue owner. I won't mention this again in this issue.

See Also: → 1827232

If Firefox ends up using wayland directly (without going through a separate toolkit), it will still be possible to allow creating dialog windows - native file picker, etc. - using Gtk. Given that the toolkit wants to manage its own connection to wayland, probably with different extensions enabled than Firefox, I'm wondering if the best solution might be to have Firefox run a separate "dialogs" process with an IPC interface. The toolkit would only be initialized in the dialogs process, not in the main Firefox UI process. The dialogs process could potentially also be used to retrieve desktop-integration settings from the toolkit.

Gtk (GdkWayland) already has interfaces in place to set a dialog's parent to a wayland xdg_toplevel handle exported from a separate process - https://docs.gtk.org/gdk4-wayland/class.WaylandToplevel.html - for exactly this use case. This interface is available on both Gtk4 and Gtk3 (>= 3.22), and is how the portal dialogs are implemented. Handles are passed between processes using the currently unstable XDG foreign protocol: https://wayland.app/protocols/xdg-foreign-unstable-v2

Using the xdg portal interfaces if available for some dialogs and for retrieving desktop-independent settings like color scheme (dark/light pref), high contrast, reduced motion might still be a good idea when that's possible.

I went through https://docs.gtk.org/gtk4/migrating-3to4.html (guide how to migrate apps from Gtk3 to Gtk4) and it will be huge amount of work to port Firefox from Gtk3 to Gtk4. The changes may be large and may need completely different code (we may need to create gtk4 widget for it).

Such massive effort needs firm justification why we'll do that.
Right now I see only one reason to use Gtk4 - xdg-popup reposition:

https://gitlab.gnome.org/GNOME/gtk/-/issues/1986
https://lists.freedesktop.org/archives/wayland-devel/2019-October/040968.html

I'm afraid such fix can't justify the requested mount of work.

Attached patch basic-config.patch β€” β€” Splinter Review

If anyone is interested there's a patch which configures firefox to build with Gtk4. You also need to build with 'ac_add_options --without-sysroot' option at .mozconfig.

Assignee: nobody → stransky

(In reply to Martin StrΓ‘nskΓ½ [:stransky] (ni? me) from comment #29)

Such massive effort needs firm justification why we'll do that.
Right now I see only one reason to use Gtk4 - xdg-popup reposition:

See also Bug 1568722, which is the reason I'm watching this.

Moving to GTK 4 could fix the problem with huge cursor on 250%/150% scaling on Wayland (on any scale non-equal to 100%/200%/300%).

See Bug 1755231.

We should focus on backport fixes to Gtk3 - that's more realistic variant.

I dived a little bit inside source code and I want to share some information that maybe is already known.

Grep the entire codebase for gtk, but including only files with the following extensions: .c, .cc, .cpp, .h, .ipdl, .ipdlh, .js, .jsm, .py and .rs there are 365 unique files containing the string gtk. Instead the total number of lines where the gtk word is present are 6630. The most of the code reside under the folder widget/gtk.

The question is, a possible porting attempt can be done step by step or need to be done in a single step?

(In reply to Massimo Fidanza from comment #35)

The question is, a possible porting attempt can be done step by step or need to be done in a single step?

Gtk4 has very different API than Gtk3 (while functionality from Firefox POV is almost the same beside bug fixes).
That means you need to fix everything to get it working. You can't have part of Firefox use Gtk3 and part Gtk4.

You can use patch from https://bugzilla.mozilla.org/attachment.cgi?id=9351192&action=diff and fix build issues step by step.

Yeah, we could in theory land something like that but opt-in (something like a different toolkit name or so), and let people fix build issues as needed.

(In reply to moz-nuc from comment #21)

The Qt Company have demonstrated poor behaviour as stewards of that toolkit with regard to open source releases, for instance recently making 5.x updates commercial-only, with little notice and before 6.x achieved feature parity, see:

https://www.phoronix.com/news/Qt-5.15-LTS-Commercial-Phase
https://www.theregister.com/2021/01/05/qt_lts_goes_commercial_only/

Qt might be shiny, but porting Firefox would put it at risk of the whims of the commercial decisions of The Qt Company (or a future owner).

That's not entirely true. LTS updates are delayed by 12 months to avoid issues with the KDE Qt contract to keep KDE open.
However most of these patches that go into LTS are also available inside the KDE Qt5 Patch collection:
https://community.kde.org/Qt5PatchCollection

(In reply to Martin StrΓ‘nskΓ½ [:stransky] (ni? me) from comment #36)

(In reply to Massimo Fidanza from comment #35)

The question is, a possible porting attempt can be done step by step or need to be done in a single step?

Gtk4 has very different API than Gtk3 (while functionality from Firefox POV is almost the same beside bug fixes).
That means you need to fix everything to get it working. You can't have part of Firefox use Gtk3 and part Gtk4.

You can use patch from https://bugzilla.mozilla.org/attachment.cgi?id=9351192&action=diff and fix build issues step by step.

Is the situation similar to the GTK2 -> GTK3 transition? Then using a different toolkit might cause the same amount of work from what I've heard what other projects said.
GTK4 goes more in the direction to alienate everything that isn't GNOME. The opposite of what Qt does.

GTK4 goes more in the direction to alienate everything that isn't GNOME. The opposite of what Qt does.

People might have different experiences, but the fact that QT still, even in version 6, does not support text_input_unstable_v3 - after over five years - and thus doesn't have onscreen keyboard support on Gnome or Sway speaks to the opposite, IMO. In this particular case it instead implements some downstream alternatives v2 and v4, v2 being supported by Kwin - but nothing of that is upstream in wayland-protocols.

So even if we were to port to the latest QT version OSK would only work on Kwin (and maybe some niche compositors).

That being said, I personally would favor freezing X11 on GTK3 and only move the Wayland bits to something new - be it another toolkit or a full own implementation (which IMO could well end up smaller/lighter than the glue code to any existing toolkit - maybe apart from theming support, if we want to have that).

(In reply to Robert Mader [:rmader] from comment #40)

GTK4 goes more in the direction to alienate everything that isn't GNOME. The opposite of what Qt does.

People might have different experiences, but the fact that QT still, even in version 6, does not support text_input_unstable_v3 - after over five years - and thus doesn't have onscreen keyboard support on Gnome or Sway speaks to the opposite, IMO. In this particular case it instead implements some downstream alternatives v2 and v4, v2 being supported by Kwin - but nothing of that is upstream in wayland-protocols.

Why should they implement an older protocol? If read correctly the reason is that v3 doesn't provide the same features that v3 has. For this reason Qt submits v4 of the protocol to Freedesktop.org:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/39

Chromium has similar issues with text_input_unstable_v3:
https://bugs.chromium.org/p/chromium/issues/detail?id=1039161#c12

You can read more in the Qt Wiki here:
https://wiki.qt.io/QtCS2021_-_Wayland_text-input-unstable-v4_protocol
Or the Qt bugtracker:
https://bugreports-test.qt.io/browse/QTBUG-96417

There are other issues in GTK4 that break non-GNOME users on X11 and Wayland such as forced CSD's. The support for each environment would be
required by Mozilla to do as GTK expect the app developer to follow each HIG depending on the environment for GTK4.
GTK apps look and feel alien. Qt allows uniform support for all platform no matter if Linux or any other platform.

So even if we were to port to the latest QT version OSK would only work on Kwin (and maybe some niche compositors).

That being said, I personally would favor freezing X11 on GTK3 and only move the Wayland bits to something new - be it another toolkit or a full own implementation (which IMO could well end up smaller/lighter than the glue code to any existing toolkit - maybe apart from theming support, if we want to have that).
To me such an idea sounds like a mine field implementing something akin to Xlib but for Wayland on their

Why should they implement an older protocol?

They've added support for v1 because weston only supports it. I don't understand why they failed to see v3 and wlroots users.

I'm advised against v4 from an input method developer. Presumably it's still WIP.

(In reply to Robert Mader [:rmader] from comment #40)

GTK4 goes more in the direction to alienate everything that isn't GNOME. The opposite of what Qt does.

People might have different experiences, but the fact that QT still, even in version 6, does not support text_input_unstable_v3 - after over

I don't think this is relevant at all. If anybody it going to work to port Firefox to Qt there isn't any issue with that. We can create new widget/qt subdir and allow to use such backend (we had that before).

But dot expect from Mozilla widget team to do that - there are two people (Emilio and me) who work on Linux/toolkit code and we barely keep recent widget code up to date and fix all X11/Wayland/Gtk whatever bugs.

So patches are welcome (as well as for Gtk4 port etc.) but if you post here to persuade me (or anybody else) to do the work please don't do that - you waste our time.

(In reply to Thaodan from comment #41)

Why should they implement an older protocol? If read correctly the reason is that v3 doesn't provide the same features that v3 has. For this reason Qt submits v4 of the protocol to Freedesktop.org:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/39

My point being that they failed to support the latest upstream protocol (and thus standard) for over five years, hurting the ecosystem. But well, as per Martins comment we're getting offtopic here.

There was a Qt port, and it was explicitly removed in bug 1282866. I don't think we'd take patches to add Qt back.

Not addressing this issue might waste even more of your precious time as GTK3 will become less supported and tested on modern platforms and in turn you will receive more bug reports or need more time finding workarounds for things which have already been fixed in GTK4.

See Also: → 1869299

(In reply to darkdragon-001 from comment #46)

Not addressing this issue might waste even more of your precious time as GTK3 will become less supported and tested on modern platforms and in turn you will receive more bug reports or need more time finding workarounds for things which have already been fixed in GTK4.

GTK3 is stable and used by a vast majority of GTK projects out there. Only GNOME apps are moving to GTK4 and not only to GTK4 but also to libAdwaita.

If GTK5 kills the theme engine and X11 support it effectively becomes useless for non GNOME applications. This isn't the time to rush into GTK4 without knowing if GTK long-term will continue to be an option.

It might be more useful to think about long-term GTK3 support or alternatives to GTK.

(In reply to clement.lefebvre from comment #47)

(In reply to darkdragon-001 from comment #46)

Not addressing this issue might waste even more of your precious time as GTK3 will become less supported and tested on modern platforms and in turn you will receive more bug reports or need more time finding workarounds for things which have already been fixed in GTK4.

GTK3 is stable and used by a vast majority of GTK projects out there. Only GNOME apps are moving to GTK4 and not only to GTK4 but also to libAdwaita.

If GTK5 kills the theme engine and X11 support it effectively becomes useless for non GNOME applications. This isn't the time to rush into GTK4 without knowing if GTK long-term will continue to be an option.

It might be more useful to think about long-term GTK3 support or alternatives to GTK.

Sorry but GTK5 is not much longer time to be released? and it's x11 deprecation is fully confirmed?
about GTK4, have some feature that can be utilized like dma-buf in ngl/vulkan backends? or it's can't affect way how webrender oflloading videos? or a webrender compositor can handles its?

GTK4 too have amount of features and improvements includes newest gpu unified backend, it's can be improve? or will be limited just for gtk4 widgets? in case can be used without use some gnome dependency like libadwaita.

Have some plans for future port to QT6? QT6 looks to find paths for resolve problems and modernize in a way that community and developers likes.

Sorry for amount of questions

https://bugzilla.mozilla.org/show_bug.cgi?id=1701123#c48

eliascontato@protonmail.com, a Qt port was attempted once, but it was removed from the source tree after not being maintained. Without Mozilla's support (which doesn't appear to exist for the idea, currently) I believe that I speak for most here that there is little chance that a Qt port for Gecko shall take precedence over the FF's official GTK3 version. However, if you want to discuss this topic to try to convince Mozilla, I suggest you follow https://bugzilla.mozilla.org/show_bug.cgi?id=1827232#c0.

The design of the widget code (if you ignore the oddness of mixing gtk2 and 3 for plugin reasons) should still allow anyone to target any widget toolkit. Including FLTK or the Fox toolkit providing enough work went into it. Whatever the decision or direction Mozilla goes in if it is GTK4 and/or a renewed Qt effort I believe it is important to ensure the widget code stays modular not only for cross-platform reasons but because GTK may not stay the top dog once GTK3 apps start dying out.

Blocks: 1916189
No longer depends on: 1916189

To have native GTK emoji picker, Firefox must be ported to GTK4 πŸ€”

A browser doesn't really need an emoji picker, you should rely on the one provided by your desktop environment instead.

Implementing an emoji picker into every single application isn't a scalable solution.

I would argue that GTK built-in emoji picker is the platform-specific emoji picker for GTK/X11 platform (and probably GTK/Wayland too).

when I want to add an emoji in a textarea like the one I'm using to post this comment, I'd like to be able to take advantage of my OS's native emoji-picker popup.
When firefox will be ported to GTK4, it will be possible to call the emoji-picker from all text entries with a CTRL+;.

Why are unicode-emoticons important enough to upend widget support on Linux? Will GTK4 be done so that it need not exclude or compromise or overwrite the existing GTK3 widget code?

I actually need GTK2 support back and restoring that for my purposes is going to be more difficult because GTK3 was intertwined with GTK2. I really hope this won't be repeated for GTK4 support.

(In reply to Thomas Clavier from comment #51)

To have native GTK emoji picker, Firefox must be ported to GTK4 πŸ€”

Does it? GTK3 also has an identical emoji picker accessible via Ctrl+; and Ctrl+., so exposing it in Firefox would be independent of a move to GTK4. There are a bunch of related bugs already (bug 1452036, bug 1576353, bug 1646965, bug 1716012, bug 1844959).

Will look at the Gtk3 emoji picker dialog.

Alias: gtk4
Flags: needinfo?(stransky)

If Firefox stays onΒ GTK3, it will move further andΒ further away fromΒ system integration. Right now, two notable features are being added toΒ Gnome: accent color change andΒ nautilus as aΒ file select/save widget. I checked Firefox inΒ FedoraΒ 41Β Beta:

  • TheΒ accent color (default, notΒ modified byΒ authoring styles) doesΒ not follow theΒ one selected inΒ theΒ system, even onΒ theΒ interface elements ofΒ theΒ browser itself.
  • TheΒ file select/save widget is theΒ same fromΒ GTK3, which looks like aΒ museum piece inΒ theΒ new GnomeΒ 47.

Besides, there are aΒ lot ofΒ little things (like theΒ appearance ofΒ theΒ scrollbar fromΒ GTK3 andΒ soΒ on), which inΒ general addΒ up toΒ theΒ picture ofΒ anΒ obsolescent program.

I wish Firefox many more years andΒ prosperity! Please upgrade toΒ GTK4.

#c58

firefoxic.dev@gmail.com, I expect that widget.use-xdg-desktop-portal.file-picker should remediate that, considering that the file picker portal should be newer than the one integrated into the application by the toolkit.

Also, I believe accent colors can be accessed outside GTK, since it's a cross-desktop standard. It's just a matter of implementing support for it.

As for the file chooser, perhaps we should default to the portal if available? The GTK3 picker doesn't even support thumbnail view, which is a pretty big usability issue.

(In reply to firefoxic.dev from comment #58)

If Firefox stays onΒ GTK3, it will move further andΒ further away fromΒ system integration. Right now, two notable features are being added toΒ Gnome: accent color change andΒ nautilus as aΒ file select/save widget. I checked Firefox inΒ FedoraΒ 41Β Beta:

  • TheΒ accent color (default, notΒ modified byΒ authoring styles) doesΒ not follow theΒ one selected inΒ theΒ system, even onΒ theΒ interface elements ofΒ theΒ browser itself.
  • TheΒ file select/save widget is theΒ same fromΒ GTK3, which looks like aΒ museum piece inΒ theΒ new GnomeΒ 47.

Besides, there are aΒ lot ofΒ little things (like theΒ appearance ofΒ theΒ scrollbar fromΒ GTK3 andΒ soΒ on), which inΒ general addΒ up toΒ theΒ picture ofΒ anΒ obsolescent program.

I wish Firefox many more years andΒ prosperity! Please upgrade toΒ GTK4.

Firefox uses almost zero system styling as it is and what little they do use they typically emulate it using the power of gecko. Seems intentional and by design and not entirely unheard of in Mozilla's history.

(In reply to Matt A. Tobin [:nsITobin] from comment #61)

Firefox uses almost zero system styling as it is and what little they do use they typically emulate it using the power of gecko. Seems intentional and by design and not entirely unheard of in Mozilla's history.

I wasn't talking about styles, I was talking about system widgets and user preferences.

No matter what the browser's own styles are, when I open/save a file, I expect to see a dialog box from my system for that action. After all, it's no longer an internal browser affair, at that point we're out of the browser's area of responsibility and into the system's area of responsibility.

The same goes for the user's system preferences. Whatever the browser's own styles are, I as a user expect the browser to follow my preference if in the system settings I have chosen:

  • dark color scheme,
  • reduce animation,
  • high contrast,
  • overlay or hard scrollbar,
  • accent color, etc.

The first three seem to be fine. The rest are worse. I turned off the overlay scrollbar by default in Gnome settings (for testing, not for use), and in Firefox it's still overlay. I have to additionally toggle this in Firefox settings, which seems odd and exhausting. And I haven't even mentioned the appearance of the scrollbar yet. But I will! I don't understand at all why every browser brings its own implementation of the scrollbar in every OS (except macOS, yeah), even though it was obviously easier, cheaper, and better to just use the system scrollbar (because it's in every OS and DE).

Now the accent color is added as well. It will be very strange to see blue outlines, checkboxes and other elements blue, when in the whole system they are green or purple. And it's not a matter of the browser's own styles either. The browser can still draw the shape and appearance of buttons, checkboxes, radio buttons, and other elements in its own way, but I would expect to see some of them and the stroke around them in the color I have chosen in the system.

Yes, these system settings can and probably should be duplicated in the browser settings (as is already done for choosing the color scheme, for example), because if the user wants browser settings different from the system settings, it is strange to prevent him from doing so. But by default I would like the browser to follow the user's system preferences.

Sorry for the verbosity.

GTK3 Firefox certainly already loads the GTK+ color scheme - I can see it uses the same colors in its UI as are in the system color scheme.
And switches these colors when system light/dark color scheme is switched too.

In Cinnamon, MATE, Xfce and many other desktops, there is no such thing as an "accent color". You choose an entire "theme", not just a color.

It makes very little sense for a desktop which already supports themes to ask users to also pick a color, so this new idea of accent-colors isn't necessarily going to be supported in themeable environments.

Firefox integrates really well with GTK themes. Personally I really don't care whether it supports accent colors in non-themeable desktops, as long as that doesn't break compatibility with desktop themes.

No longer blocks: 1568722
See Also: → 1568722
No longer blocks: 1836886
See Also: → 1836886
Attached patch gtk4-config.patch β€” β€” Splinter Review

(In reply to Martin StrΓ‘nskΓ½ [:stransky] (ni? me) from comment #30)

Created attachment 9351192 [details] [diff] [review]
basic-config.patch

If anyone is interested there's a patch which configures firefox to build with Gtk4. You also need to build with 'ac_add_options --without-sysroot' option at .mozconfig.

Added a patch that extends your patch a bit. It now got a "cairo-gtk4" config option that is wayland only for now. With that patch applied I tried building all 5 existing gtk3 switches and they all seem to work just fine. This way you can start porting to gtk4 without touching gtk3. At least that seems like a good plan to me. A few more tweaks to the build system are needed for having full support for gtk4 but I don't think it's that much. So the porting could then, if/when someone decides to do it :), be done in the widget/gtk4 directory.

As I thought only a few tweaks needed for it to configure properly and start building with the "cairo-gtk4" switch. A few things I noticed this far:

  1. GTK4 does not use ATK so that should be removed.
  2. If you set MOZ_WIDGET_TOOLKIT=gtk for all versions of gtk you can use a MOZ_GTKX boolean for differ if needed. This will not break existing gtk3 support.
  3. If you set gtk cflags without version it'll work with all versions of gtk automatically. This will make it a breeze to port to gtk5. :) This will break existing gtk3 builds though, if not set both, and must be fixed properly.

Setting MOZ_WIDGET_TOOLKIT="gtk" for all versions might be the best solution. And then use MOZ_GTKX boolean and MOZ_GTK_VERSION number to differ. Already found a few places to use it for future versions, eg for setting widget directory:

if toolkit in ("android", "cocoa", "uikit", "windows") :
    DIRS += [toolkit]
elif toolkit == "gtk":
    DIRS += ["gtk%s" % CONFIG["MOZ_GTK_VERSION"]]
Attached patch gtk4-config-v2.patch β€” β€” Splinter Review

And in the next, and possibly final, step it would be nice if the gtk headers are not versioned. Wayland headers are not so why would gtk be?? If it would work without version in gtk headers most of the build system will just continue working when upgrading gtk. This is how it looks now:

if CONFIG["MOZ_WIDGET_TOOLKIT"] == "gtk":
    CXXFLAGS += CONFIG["MOZ_GTK3_CFLAGS"]

Take away the version and it'll just continue working forever.

Attached patch gdkrgba.patch β€” β€” Splinter Review

Noticed that gdkcolor is deprecated and should be replaced with gdkrgba and it's already backported to gtk3. Haven't used native code in decades so consider my patch a wip and use with extreme caution! Basically the order of the parameters are altered and it's now using floats. So some porting could already be done in the gtk3 port. That was nice because that file was not in the widget directory and it was the only thing that needed porting in it. Happy new year everyone and hopefully 2025 will be the year of a decently working gtk4 port. :)

Don't think I've seen gtk_init since gtk2, recommended replacement is gtkapplication already in gtk3. Though gtk_init still exists in gtk4 it doesn't take any arguments, and gtk_main is completely gone. There must be a mainloop started somewhere right?! Would it be possible to move to gtkapplication already in gtk3?

https://hg.mozilla.org/mozilla-central/file/tip/dom/ipc/ContentChild.cpp#l723

I don't understand that much rust code yet but it may be so that gtkapplication is already used so that is nice!! I did find gtk_main in use in the updater and also a few honorable mentions. :) In gtk4 gtkcontainer is gone. So adding something to a window is done with gtk_window_set_child instead of the old container stuff. And gtkbox has renamed pack_start to append. It doesn't seem like the end of the world for porting most stuff.

https://hg.mozilla.org/mozilla-central/file/tip/toolkit/mozapps/update/updater/progressui_gtk.cpp#l111

Yes I found out that gtkapplication is in use with the crashreporter at least. First time ever reading rust code (assuming it's rs) but I can already say that the persons that wrote the gtk crashreporter really know what they're doing. Not only is the code as pretty as the Mona Lisa they 're also consistently not using deprecated stuff but instead use new recommended stuff like ie gtkapplication, gtk_widget_set_visible and plain gtkbox. Skimming over the crashreporter gtk code I could only find a few things that need to be fixed in gtk4: gtk_window_new takes no argument (all windows are toplevel in gtk4 :)), container is gone and use append for box. Would probably just take a few minutes to port the crashreporter.

https://hg.mozilla.org/mozilla-central/file/tip/toolkit/crashreporter/client/app/src/ui/gtk.rs#l51

Looking around for more deprecated stuff I noticed that both gtkstyle and gtkiconset are gone in gtk4. Gtkstyle is replaced by gtkstylecontext already in gtk3 and even though it does exist in gtk4 it's listed as deprecated. Jesus make up your minds! :( Now it seems like you're supposed to set css globally and then add class names to individual widgets. I just tried it in python and it works, looks something like this:

provider = Gtk.CssProvider.new()
provider.load_from_string(""".my-widget {background-color: #000;}""")
Gtk.StyleContext.add_provider_for_display(my_widget.get_display(), provider, Gtk.STYLE_PROVIDER_PRIORITY_APPLICATION)
my_widget.add_css_class("my-widget")

This is not necessary for gtk4 but will probably be for gtk5 (if they're not switching to yet another thing) so better try to avoid gtkstylecontext already if possible. Looking at the gtk icon decoder, it's basically the opposite of the crashreporter, looks like leftovers from gtk2. But I tried to get rid of gtkstyle and gtkiconset at least. And maybe the whole ensure_stock_image_widget function could be removed? "Only the style of the GtkImage needs to be used, but the widget is kept to track dynamic style changes" What does that even mean?? Attaching a wip patch that tries to clean up some stuff but it does not solve that much with regards to gtk4 sadly. Gtk4 does not use pixbufs that much but instead use paintables. Ie gtk_icon_theme_load_icon is removed in gtk4 as gtk_icon_theme_lookup_icon already returns a paintable. Don't know how you get a pixbuf of a paintable but it must be possible somehow?! In any way I think the gtk icon decoder should be cleaned up from the oldest stuff used and make it more suitable for porting to gtk4.

Attached patch icon-decoder.patch β€” β€” Splinter Review

Yeah seems like a problem: https://discourse.gnome.org/t/gtk4-how-to-get-a-pixbuf-from-an-icon-now-that-gtk-icon-theme-load-icon-is-gone/5191

But that solution with using gdk-pixbuf would actually be very similar in both gtk3 and gtk4. Something like this:

  bool icon_exists = false;
  GError *error = nullptr;
  GdkPixbuf* icon;
  if (size_exists) {
    GtkIconInfo* icon_info = gtk_icon_theme_lookup_icon(
      icon_theme, stockIcon.get(), size, (GtkIconLookupFlags)0);
    if (icon_info) {
      const gchar* path = gtk_icon_info_get_filename(icon_info);
      icon = gdk_pixbuf_new_from_file_at_size(path, size, size, &error);
      g_object_unref(icon_info);
      if (icon) {
        icon_exists = true;
      }
    }
  }

Tested now and the above code works fine. Going over the rest of the gtk icon decoder I noticed that gtkiconsize is very simplified in gtk4 and gtk_icon_size_lookup is gone. I don't think all this size stuff is that important anyway as scaling is invented along with svg icons. So my rather educated guess is that the current gtk3 icon decoder could be made around 97% compatible with gtk4 already. :) A few ifdefs away only and porting will be done.

Got stuck reading up on changes in gtk4 and also mozilla's coding guidelines. But I've been going over the gtk icon decoder line by line for a few days now and finally managed to squeeze out all deprecated stuff and it now builds without warnings in both gtk3 and gtk4 (only a few ifdefs needed). But man there was old code in it, must've been written for gtk1 back in the day initially. It now also supports scale factor though state seems to be gone in newer icon stuff, maybe not needed? As gtk got smarter over the years lots of code was just made redundant and could be removed. Here it is: https://gitlab.com/xerxes2/mozilla/-/blob/main/nsIconChannel.cpp?ref_type=heads

So if more people want to help out in porting just use "#ifdef MOZ_GTK4" and it'll work just fine in the current gtk3 port too. Only needed outside of the widget/gtk directory otherwise just use widget/gtk4 instead. And I also ran into a page that outlines upcoming plans for gtk5 and so far it seems to be mostly about removing deprecated stuff. But gtk4 is a significant update that has to be said.

https://docs.gtk.org/gtk4/migrating-4to5.html

Building now goes as far as the widget/gtk directory. So outside of that directory it doesn't seem to be that big of a deal to port. Noticed that gdkscreen is gone in gtk4 though, it's mostly replaceable with display/monitor already in gtk3 but couldn't find a replacement for gdk_screen_get_resolution, not even in gtk4, so had to calculate dpi manually which seems a bit strange. Though I always thought it was a bit weird with having all three of display, monitor and screen so I guess the screen got what's coming for him! :)

But now I ran into some serious issue with gtkcontainer is gone and the gtk3 port is very heavy into that one. And gdkwindow is renamed gdksurface but I think that is mostly a reformatting thing at least. But replacing gtkcontainer may be the single biggest issue in porting to gtk4. They have their own mozcontainer which has to be tweaked to do without gtkcontainer. In gtk4 you're basically just using gtk_window_set_child and gtk_box_append now when container is gone. At least in theory it sounds simpler. :) Also gdkevent is very different in gtk4 and gtk_main and friends are gone so that stuff will have to be replaced somehow. And they're still very busy deprecating stuff in gtk4 and the "port to gtk4" page seems to be getting larger every day. So not all is bad that porting is slow, better check the docs before using something because it might be deprecated already.

Yes, from my understanding there are lot of API changes which actually doesn't change anything, just moved Gtk from X11 to Wayland terms.
But note that we need to support both Gtk3 and Gtk4 (Gtk5) on the same time and runtime (if you want to ship Gtk4 port by default) so it's kinda PITA.

(In reply to Martin StrΓ‘nskΓ½ [:stransky] (ni? me) from comment #83)

Yes, from my understanding there are lot of API changes which actually doesn't change anything, just moved Gtk from X11 to Wayland terms.
But note that we need to support both Gtk3 and Gtk4 (Gtk5) on the same time and runtime (if you want to ship Gtk4 port by default) so it's kinda PITA.

It's true the gtk3 port works fine (used Fx since it was called friggin Netscape and this is the best port) but as gtk3 is basically eol already and put on life support it'll have to be replaced. Talk about porting to qt6 or "pure wayland" (don't even know what that means) seem like nothing more than hot air to me. Imho gtk4 is the clear frontrunner in the race of replacing the gtk3 port on *nix.

Supporting both gtk3 and gtk4 at buildtime is easy and am already doing it. Outside of the widget/gtk directory it seems to be mostly fixes of around 1-10 lines that works fine with using ifdef. And then use widget/gtk4 for the proper porting. This is working just fine using the cairo-gtk3/cairo-gtk4 switches. Don't know what you mean by runtime? I personally have no interest in what binaries Mozilla ship if that is what you mean. Any distro could ship whatever they want using the options supplied by the build system, as they always do.

"pure wayland" (don't even know what that means)

It means using libwayland-client and the Wayland interfaces (https://wayland.app/protocols/) directly. Firefox already makes use of these, see anything that calls the functions defined in widget/gtk/wayland/.

Don't know what you mean by runtime?

It means the code must support both GTK 3 and GTK 4 in a single binary, not just as a build-time switch, and decide on launch which one to load.

(In reply to Jan Alexander Steffens [:heftig] from comment #85)

"pure wayland" (don't even know what that means)

It means using libwayland-client and the Wayland interfaces (https://wayland.app/protocols/) directly. Firefox already makes use of these, see anything that calls the functions defined in widget/gtk/wayland/.

I see, never heard of that. Only ever used straight gtk/qt. You would have to reinvent a few wheels to do that though. But then again, you don't have to maintain a gtk port. I can see a few problems with desktop integration doing that but earlier in this ticket there was some talk abot xdg-portal something?! Before hitting a brick wall (or maybe I should say container) one of the last build errors I got was about gtk_show_uri. As it turns out it does exist in gtk4 but is not identical and both of them are already marked as deprecated anyway.

  #ifdef MOZ_GTK4
  GtkUriLauncher* launcher = gtk_uri_launcher_new(spec.get());
  gtk_uri_launcher_launch(launcher, nullptr, nullptr, nullptr, nullptr);
  g_object_unref(launcher);
  #else
  GUniquePtr<GError> error;
  gtk_show_uri(nullptr, spec.get(), GDK_CURRENT_TIME, getter_Transfers(error));
  if (error) {
    NS_WARNING(
        nsPrintfCString("Cannot launch flatpak handler: %s", error->message)
            .get());
    return NS_ERROR_FAILURE;
  }
  #endif

The new stuff was not available in gtk3 so could not test it in Firefox but tested it on the side and it does give you an app-chooser popup window. But such stuff may be possible to use with xdg-portal, don't know much about it? But, even if it would be technically possible to use pure wayland I could see some problems with it still. Porting to gtk4 would (if implemented, some work to do still outside of wayland) add support for x11 for another decade or so.

Don't know what you mean by runtime?

It means the code must support both GTK 3 and GTK 4 in a single binary, not just as a build-time switch, and decide on launch which one to load.

Firstly, never heard of anyone on *nix using binaries of Firefox supplied by Mozilla. Maybe it's a thing but I must've missed it. And secondly, why? Is Mozilla still supporting runtime binaries of gtk1 and gtk2 ports also? Got me thinking of that old Robin Williams classic, the remake by Mozilla productions would of course be called "dead toolkits society"!! :) Mozilla could continue to ship binaries of gtk1-3 ports in all eternity for all I care. I do care about Firefox supporting gtk4 in source though.

But I have been thinking about this lately and started digging around my own box a little. And basically all my favorite apps like Firefox, gnome-terminal, evince and shotwell are all still on gtk3. Gimp would be an honourable mention but it's playing by its own rules so let's not go there. I'm almost beginning to think that gtk4 might be cursed. :) So much fud going around like "enforcing libadwaita" and "dropping x11" etc. The biggest change I've noticed with gtk4 this far is that the old treeview is gone and the new one is a bit tricky to use, but powerful when it's set up correctly. Other than that I can't tell that much difference to gtk3. But now when finding out that gtkcontainer basically is the Luke Skywalker of the firefox gtk3 port it was not that funny that it's gone in gtk4. Starting touching stuff in the widget/gtk directory is very dangerous if you don't know what you're doing, I'm stuck in rtfm mode right now.

Did some checking now on the status of gtk4 in those apps I mentioned earlier. Gimp and Firefox you already know about. And gnome-terminal seems pretty much dead, so I went looking for some replacement terminal on gtk4. Turns out there is a new terminal on gtk4 called Ptyxis that looks really good. Only tested it a few hours but looks promising, feels snappy and got themes. So I went to take a look at what's up with Evince and looking at their release notes for the upcoming 48 alpha: "Use updated image for both gtk3 and gtk4", it actually looks like gtk4 support is incoming! And they even seem to support both gtk3 and gtk4 with a build switch. hint And finally I looked at Shotwell and not so easy to find but looking at the buildscript it already has switched to gtk4. On my distro it's still on gtk3 though, could possibly be that gtk4 support is coming in the next big release. So there has been some movement to gtk4 after all, it may not be that cursed. Basically only Firefox and Gimp left to make the switch soon, a chicken race to the end. :)

"Evince" had to be forked to "Papers" to make the Gtk4 port happening. You can read the full story here. Hope that we don't have to fork Firefox to make the Gtk4 port happening...

(In reply to Jan Alexander Steffens [:heftig] from comment #85)

Don't know what you mean by runtime?

It means the code must support both GTK 3 and GTK 4 in a single binary, not just as a build-time switch, and decide on launch which one to load.

There may be build-time switch only but that means Mozilla binaries will stay on Gtk3 and Gtk4 will be used by distros only. But that means distros are supposed the Gtk4 bugs then.

(In reply to darkdragon-001 from comment #88)

"Evince" had to be forked to "Papers" to make the Gtk4 port happening. You can read the full story here. Hope that we don't have to fork Firefox to make the Gtk4 port happening...

I missed that drama, though I do try to check in to phoronix daily to get the latest open source action. :) But I forgot to mention Inkscape earlier and that gtk code base is massive! Looking around a bit they seem to have been in porting to gtk4 mode for years already. https://gitlab.com/inkscape/inkscape/-/issues/4802

But speaking of Firefox porting from gtk3 to something else will eventually have to be done, so if Mozilla does nothing forking will be an option. Don't know if Iceweasel/Icecat are still around? But if anyone got server space feel free to put up the mozilla source and give me committing access so things can start moving a bit at least. Not as a fork more as a proof of concept. This will put some heat on the beancounters at Mozilla hq too. Maybe some better coders than me will start committing to it? I have put up three goals now at least. The first is to get it to build all the way through without errors. The second that it actually shows a window with something in it. And the third that it will register input events. Not until all those three work you can start fixing bugs and add missing features. Already the second will be very difficult, call it a gut feeling for now. :)

(In reply to Jens Persson from comment #90)

if anyone got server space feel free to put up the mozilla source and give me committing access so things can start moving a bit at least

You could just create a fork of https://github.com/mozilla/gecko-dev for this purpose.

(In reply to Martin StrΓ‘nskΓ½ [:stransky] (ni? me) from comment #89)

(In reply to Jan Alexander Steffens [:heftig] from comment #85)

Don't know what you mean by runtime?

It means the code must support both GTK 3 and GTK 4 in a single binary, not just as a build-time switch, and decide on launch which one to load.

There may be build-time switch only but that means Mozilla binaries will stay on Gtk3 and Gtk4 will be used by distros only. But that means distros are supposed the Gtk4 bugs then.

Based on my findings this far my suggestions would be:

  1. My config-v2 patch will add basic support for a cairo-gtk4 build option which is wayland only for now. Name is not important, might as well be called cairo-gtk4-wayland-only or something.
  2. By removing the version from the gtk cflags define it'll support all versions of gtk. If there are no technical arguments against this this is a no brainer because all those build files will have to be updated anyway. This would make the build system around 98% compatible with all versions of gtk automatically.
  3. Add a MOZ_GTK_VERSION (maybe already exist, not sure) define that could be used to plug a few remaining holes in the build system.

By doing those three (basically nr 2 and 3) things the build system would almost (there is always something) by 100% support all upcoming versions of gtk with only having to edit one friggin file. Basically you would use the widget/gtk(x) directory for the heavy version specific stuff and ifdef outside of it. This would be my 2 cents at least.

(In reply to Botond Ballo [:botond] from comment #91)

(In reply to Jens Persson from comment #90)

if anyone got server space feel free to put up the mozilla source and give me committing access so things can start moving a bit at least

You could just create a fork of https://github.com/mozilla/gecko-dev for this purpose.

Hey thanks for the tip!! Did not know about that option whatsoever. Had not used github in quite some time but forking it was easy when I managed to find the right button. :) Did have to update a few ssh files after that but cloning is now in progress and seems to be working fine. But man it's a massive clone.

So I got started a bit this evening on github. Updated the build system with what I got so far and addded a short readme.
https://github.com/xerxes2/gecko-dev

It only builds for a few seconds now, crazy to think that I got it to build for around 20 minutes, digging up all that will take a few days/weeks though. As I've said before outside of widget/gtk almost only small fixes needed (only exception I can think of this far is the icon decoder). It's in widget/gtk the real fun starts. Far from everything I do is properly done though. Also don't bother with stuff that are not essential for the port to eventually start. Like ie I just found out that gtkclipboard seems to be gone in gtk4. It's not worth the hassle trying to find a replacement (there must be something) for it when you can't test it anyway. Better just comment such shit out and move on instead.

But about the gtk4 build switch that Mozilla may add, I don't see that happening anytime soon actually. Because that would imply that they would accept patches for the gtk4 port and that seems very far off to me. I'd think a better approach would be to port on the side and try to badmouth Mozilla in any way possible. Really rub it in that their precious binaries (why even call it open source if it's all about the friggin binaries??) are made from outdated toolkits!! Build up pressure over time is the way to go imho.

Great to see this! A git branch is so much more readable than a collection of patch files!

I suggest from experience that you start from the beginning to rebase/squash/reword commits in your branch such that it will be easier to potentially merge (some of) them.

Note that you can easily git apply the patches you attached to this thread into your Git branch.

I also suggest that you link this bug in your README.md.

I also don't see a reason why patches to using newer GTK3 (in preparation for GTK4) should not be accepted. Reducing the diff from your fork/port is a good strategy to reduce the maintenance/rebase effort going forward.

(In reply to darkdragon-001 from comment #95)

Great to see this! A git branch is so much more readable than a collection of patch files!

I suggest from experience that you start from the beginning to rebase/squash/reword commits in your branch such that it will be easier to potentially merge (some of) them.

Yeah this github option is a godsend. I will just start over no problem. Updated the readme a little bit.

(In reply to darkdragon-001 from comment #97)

I also don't see a reason why patches to using newer GTK3 (in preparation for GTK4) should not be accepted. Reducing the diff from your fork/port is a good strategy to reduce the maintenance/rebase effort going forward.

I had a bit of an evil thought yesterday. It would be really funny if the upstreams gtk3 maintainer (if there even is one) would just suddenly decide to delete all deprecated stuff and put out a new mainteinance release. I will promise you that there would be full panic mode at Mozilla hq when not even their golden child (gtk3) port would build!! :) They would be working double overtime just trying to patch it up. But, truth be told, getting rid of deprecated stuff in the gtk3 port would help maybe around 20% in the porting to gtk4 effort. Still around 80% work left that is not compatible between the major versions. And upstreams gtk3 will most likely stay as it is now forever anyway so well, if it works don't try to fix it I guess.

As Gtk is a tinny and library there's always an option to bundle it to Firefox itself. We use upstream/system gtk3 to better cooperate with other parts of desktop ecosystem, get fixes etc.

(In reply to Martin StrΓ‘nskΓ½ [:stransky] (ni? me) from comment #100)

As Gtk is a tinny and library there's always an option to bundle it to Firefox itself. We use upstream/system gtk3 to better cooperate with other parts of desktop ecosystem, get fixes etc.

Yeah I guess that's true, didn't think of that option before (always have an escape plan :)). But even so, I don't think that upstreams gtk3 will ever change that much now. And I do think that distros often want to build Firefox with already installed system libraries, which work just fine in most cases.

But now the build system is setup correctly at github and it starts building fine with gtk4. Right now I'm setting the gtk4 cflags config to the same as the gtk3 one. It may look a bit weird but it works (piggybacking on gtk3) and I don't have to edit a gazillion of build files. Also, Firefox does not use gtk that much, mostly just use its own rendering engine, so if some tricky parts could be worked out the gtk code is not that massive. And most of the gtk code I've seen this far is in very good shape (ie crashreporter is exceptional) too. So I'd say that it's not an extremely huge (ie Inkscape must be MUCH bigger) effort to port Fx to gtk4 but still a tricky one. Sure there is a few lines (haven't counted them but I'd say under a million :)) of code in the widget/gtk directory but we'll see how much can be recycled (hopefully most of it)?

IIUC GTK3/GTK4 and libhandy/libadwaita also provide a lot of widgets nowadays. So it might be possible to replace some of the custom ones with toolkit ones.

(In reply to darkdragon-001 from comment #102)

IIUC GTK3/GTK4 and libhandy/libadwaita also provide a lot of widgets nowadays. So it might be possible to replace some of the custom ones with toolkit ones.

Don't know if introducing more deps is a good idea, got enough problems already, but for the sake of argument, what should they be used for? Outside of more stand-alone things (ie app/file-chooser and crashreporter) the only thing I can think of that Fx use gtk for is right-click menu, that one looks like it's gtk.

But this got me thinking a bit, maybe not app/file-chooser would work but the crashreporter may be portable to gtk4 already as it looks like it's completely independent. Maybe someone should look into it and if it's possible port the crashreporter to gtk4 and submit a patch to Mozilla?! I don't know how rust picks gtk version though (probably hardcoded somewhere to their favorite version :)). But it would be quite sad also if all we managed to do (ticket is 4 years and counting) was to port the friggin crashreporter (haven't even seen it in years)! :) There is a build switch for it so I just disable it for now.

Time for sitrep. I've now commited everything I got this far to github. The buildsystem works fine now and it builds for a bit more than 20 minutes until it stops. On my computer (amd six-core) it takes a bit more than 30 minutes to build Fx from scratch so 2/3 is done, in build time at least. :) The only thing I know of that is broken now is event stuff, but I must say that the event stuff does not scare me that much anymore. It actually looks like it'll be "fairly" easy to fix. So it builds fine right up until it hits this line: https://github.com/xerxes2/gecko-dev/blob/a468752bef58ffb133f0168c624d5b91f249bb0f/widget/gtk4/MozContainer.h#L49

And this is when the going gets tough! :) Yes the infamous gtkcontainer is back (like the dude with the hockey goalie mask in the horror movies). So the question now is: 1. Should gtkcontainer be replaced? and 2. If the answer in 1 is yes, with what? My short list would be plain gtkwidget or gtkbox but I don't really know. But for everyone that wants Fx up and running on gtk4 this is the time to step up and do something about it!!

Just one more thing, I haven't found yet where the gtk mainloop is started from. There must be one right?? The gtk_init function exists and works fine in gtk4 too without arguments, but it does not start the mainloop. The only ones I know of that starts the mainloop are gtk_main which is gone in gtk4 so that one will show up with build error, g_application_run and there should be something directly in glib too which I haven't seen in decades. Just in case someone will try to make it start. So all and all it's getting a little hotter in here but I would not hold my breath for me to succeed on my own. :)

(In reply to Jens Persson from comment #104)

Just one more thing, I haven't found yet where the gtk mainloop is started from. There must be one right?? The gtk_init function exists and works fine in gtk4 too without arguments, but it does not start the mainloop. The only ones I know of that starts the mainloop are gtk_main which is gone in gtk4 so that one will show up with build error, g_application_run and there should be something directly in glib too which I haven't seen in decades. Just in case someone will try to make it start. So all and all it's getting a little hotter in here but I would not hold my breath for me to succeed on my own. :)

Are you looking for g_main_context_iteration()?
https://searchfox.org/mozilla-central/rev/3076c9156ef84aae253ffdc1d391e0bfab2c406b/ipc/chromium/src/base/message_pump_glib.cc#183

(In reply to Thinker Li [:sinker] from comment #105)

Are you looking for g_main_context_iteration()?
https://searchfox.org/mozilla-central/rev/3076c9156ef84aae253ffdc1d391e0bfab2c406b/ipc/chromium/src/base/message_pump_glib.cc#183

Hey thanks man. Yeah I did find searchfox a few days and actually found three mainloops but not this one. The updater is using gtk_main which would have to be fixed, crashreporter is using gtkapplication which is fine and dbus is starting the mainloop directly with glib (g_main_loop_run) so that one will also work fine with gtk4. Ok, so Firefox is running its mainloop manually if I understand it correctly.

https://stackoverflow.com/questions/23737750/glib-usage-without-mainloop

So that one will hopefully just continue to work fine with gtk4 too. And just thinking ahead a bit, I disabled the updater with a build switch but if someone would want to get it into a bit better shape you could start with switching out gtk_main for gtkapplication. Or even port the updater to rust and keep it on gtk3 for now. You could probably just model it on the excellent crashreporter. This would also be of help in the porting to gtk4 effort.

It now builds for over 30 minutes so can't be that much left now. I still get a few errors outside of widget/gtk4 though. They're usually just small errors but still they suck time and energy. But even if I do get it to build all the way through that does not mean that it'll start, far from it. I'd expect some serious rework in widget/gtk4 will be needed to get it actually up and running. Getting rid of all silly errors outside of widget/gtk4 would be a nice first step though because it would free up time to think more of how to fix widget/gtk4. I don't think it could be more than around 10 persons in the world that actually would know how to do it, and sadly I'm not one of them.

I've switched out gtkcontainer for gtkbox now just to get passed the build error but I still expect major bumps in the road ahead. And thanks for all upvotes of my posts!! As I said before, we should just keep building up pressure! :)

So there seems to not be much left to fix outside of widget/gtk4 now. But I came to a bit of halt with changes to key events so had to go and rtfm. It seems like gdkevent is not a normal struct in gtk4, it's even listed as a class. And it seems that you can not copy or edit it, which are both used in the gtk3 port. It actually looks a bit easier in gtk4 but there is a bit of weird name change from gdkeventkey to gdkkeyevent so had to adjust to that. Handling key events seems to be mostly located to 2 files so it looks quite managable but I try to not break it totally beyond repair. :) So hopefully soon I'll start making some big commits to the widget/gtk4 directory. But in the end there must also be a solution made for the gtkcontainer is gone problem. Very few calls made to gtk_container_add though so that looks a bit promising at least.

A little update, mostly good news. So it seems that I finally got the key event stuff to build. Ground zero of the key event problems is this line:
https://hg.mozilla.org/mozilla-central/file/tip/widget/gtk/IMContextWrapper.h#l251

The way the gtk3 port copies the incoming key event and use it as a normal struct just doesn't seem to work in gtk4. I first thought I should make my own fake events but it just seemed awkward so for now I'm just putting the incoming events directly in the list, no idea if it will work though. But this also means that all the struct operations don't work at all and I think you're just supposed to use method calls in events in gtk4. This is my understanding at least, but haven't dealt with this low-level stuff in a very long time so don't judge too hard!! Everything will be sorted out in due time. :)

Also, a few days ago I suddenly got build errors from the widget/gtk (gtk3) directory. It has happened a few times before so I went looking for the problem but couldn't for my life figure out where it came from?? It took me almost an hour until I finally found out that you can also list things that should be included in the build in components.conf files. But other than that the build system seems to not cause any problems and as I'm closing in on the end I don't think there will turn up any serious problems with it either. I'm also trying to just completely disable some non-essential stuff like ie clipboard and colorpicker that could be dealt with later.

The key event stuff is not completely fixed yet but now would be a good time to speak up if anyone has suggestions for it. Otherwise I'll soon start commiting what I got and we can take it from there. Right now I've just started to fix the file nsWindow.h which got tons of event errors in it. I can't say that I see the light in the end of the tunnel just yet but it can't be that much left now until it builds all the way through. Sorting out all event stuff will take some time though but the Firefox CE (community edition) is coming I can feel it! :) Continue enjoying the official gtk3 port while it lasts. :)

So I have commited quite a lot today. Almost done with the key input stuff. Had a tough fight this evening with ScreenHelperGTK.cpp effing hell!! Not a big file but very difficult to fix. I finally managed to get it to build but I had to leave it partially broken as I'm not sure of how to properly fix it. I ended up putting gdkdisplay in the list as gdkscreen is gone. This file may be of importance for it to actually start eventually so we'll see what happens? Hopefully useful debug messages will show up later.

Otherwise no major problems outside of widget/gtk4 except for one thing. In gtk4 all key names must start with GDK_KEY otherwise there is a build error. All of those have been inside widget/gtk4 though except for one friggin file that got a lot of them, it's widget/NativeKeyToDOMKeyName.h. I tried building the gtk3 port with it and it seems to be working just fine with the new scheme. Must be some intern at Mozilla that could fix it (without using any sed magic!! :)).

There is one big file coming up next at almost 10k lines (nsWindow.cpp). I don't know how much problems it'll cause but I'm expecting the worst. Hopefully that will be the last big hurdle until it will build all the way through. I'm also in the process of trying to disable as much "non essential" stuff as possible. Like all those "picker" things (app/file/color etc). This porting stuff is a tricky business as you can not test what you're doing. I can say one thing for sure though, even if the gtk4 port will be up and running "pretty soon" it'll be buggy as heck for months or maybe even years. :) All event stuff (many corner cases with key inputs etc) and all other missing features will take some time to sort out. I'm trying my best to not break things too much but it is what it is. But it's not all bad as upstreams gtk4 is always busy deprecating stuff and also adding new stuff (thanks for that) so as I always try to say, everything will be fixed in due time. :)

Got a bit of a problem. The gtk3 port is using gtkstylecontext a lot for extracting css from widgets. Gtkstylecontext is deprecated in gtk4 and already crippled down so I plan to just get rid of it already! It must be possible for Firefox to just parse the currently used gtk theme directly instead as it's just css. You can extract the theme name from gtksettings and then use gtk_css_provider_load_named to get it to a string. Would this be a good plan? The current stuff turned out to be a total nightmare, especially this file WidgetStyleCache.cpp but also nsLookAndFeel.cpp a bit. It must be possible to get rid of gtkstylecontext!? I think this may only be used if you use "system theme auto" instead of a special Firefox theme. There is also a boolean setting you can get if you prefer light or dark theme (gtk-application-prefer-dark-theme) which would be better than nothing at least. Bottom line, gtkstylecontext has to go!

GTK css has a lot of extensions that we don't really want to implement...

Probably better to hardcode the colors and such from adwaita / libadwaita

Plus Ubuntu's Yaru theme (and maybe Pop!_OS)'s system theme colors?

#c112

Emilio, that'd mean that someone would need to manually verify every time GTK updates that there's been no change, else the colour schemes would eventually diverge. Can the GTK stylesheet not be downloaded from GTK's Git repository?

#c110

I think this may only be used if you use "system theme auto" instead of a special Firefox theme. There is also a boolean setting you can get if you prefer light or dark theme (gtk-application-prefer-dark-theme) which would be better than nothing at least.

...Jens, as long as it's brought back before a public release. There'd be a flurry of bug reports from people using Koi, Yin-Yang, and similar, if Firefox suddenly ceased to automatically adhere to their system theme.

What if someone has different theme than Adwaita set?

Or maybe even a customized Adwaita?

(In reply to Emilio Cobos Álvarez (:emilio) from comment #112)

Probably better to hardcode the colors and such from adwaita / libadwaita

Thanks man, this may actually help with keeping my sanity for a little while longer. :) A few hours ago my plan was to keep using gtkstylecontext even though I know it is deprecated but it just didn't work out. I like your plan much better!! Firefox ships a few default themes and then we just hardcode Adwaita (or similar) light/dark themes. It's a start, something to build on.

(In reply to Alexander Browne from comment #113)

Plus Ubuntu's Yaru theme (and maybe Pop!_OS)'s system theme colors?

I think you can download and install any theme you like, this will be just for having something default at least.

(In reply to Mr. Beedell, Roke Julian Lockhart from comment #114)

...Jens, as long as it's brought back before a public release. There'd be a flurry of bug reports from people using Koi, Yin-Yang, and similar, if Firefox suddenly ceased to automatically adhere to their system theme.

For now this is a problem yes. But who knows, maybe gtk4 will add some methods down the road that makes it easy to get some basic css out of the currently used system theme at least? But for now it seems that you must parse the raw css theme yourself. The gtk4 port is not even building yet so there will most likely be many twist and turns ahead.

(In reply to Mr. Beedell, Roke Julian Lockhart from comment #114)
I'm aware it'd break theming (and I'm one of the people that have worked hard so that Firefox works with as many gtk themes as possible). But given the constraints:

  • Firefox won't replace its ui with a native GTK one.
  • Gtk 4+ doesn't allow us to inspect widget backgrounds, nor render widgets into textures we can inspect.

I don't think there are many realistic alternatives. For some themes, we could get named colors via gtk_style_context_lookup_color, but we'd still need a fallback.

FWIW we already hardcode some libadwaita colors when using the Adwaita theme, see bug 1869299.

(In reply to Maciej S. Szmigiero from comment #115)

What if someone has different theme than Adwaita set?

Or maybe even a customized Adwaita?

I have. I'd like to customize Firefox too (maybe with userChrome.css) if Firefox no longer follows it, e.g. selection and highlight colors.

Accent color should still be supported via the portal settings, and that influences the selection colors (and much more).

#c118

Emilio, KDE Plasma 6.x already supports theming GTK4, so I suppose as long as Firefox doesn't utilize libadwaita or attempt to force light or dark mode, it'll just work out of the box, like it would with GTK3? Perhaps these concerns are unfounded.

Accent color should still be supported via the portal settings, and that influences the selection colors (and much more).

Do you mean settings like browser.background_color, browser.foreground_color, browser.visited_color, browser.anchor_color etc or something else?
Will these colors also be used for browser UI (things like upper tabs bar background)?

Emilio, KDE Plasma 6.x already supports theming GTK4

Isn't the linked thread about making GTK4 use KDE Breeze theme and not making KDE use GTK4 theme (colors) somehow?

#c122

Maciej, nah, it's the opposite. To my knowledge, GTK4 includes the Adwaita stylesheet included by default, it's trivial to override (like GTK3). There's no interest in attempting to convince upstream GTK to include alternative stylesheets by default, much less Breeze.

The linked thread is about forcing libadwaita to adhere to GTK4 CSS, but that's irrelevant to this discussion, since libadwaita isn't something that a cross-platform project like Firefox would have any interest in implementing.

(In reply to Maciej S. Szmigiero from comment #122)

Do you mean settings like browser.background_color, browser.foreground_color, browser.visited_color, browser.anchor_color etc or something else?
Will these colors also be used for browser UI (things like upper tabs bar background)?

No, I mean https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.Settings.html

But Firefox already has pref overrides for all system colors with ui.* prefs

If I look at my own Fx right now I got 4 themes installed, light, dark, alpenglow and system-theme-auto. I can't remember installing any themes so these are probably installed by default. So I'd guess that the current plan must be that system-theme-auto will give you hardcoded adwaita light/dark from the gtksettings switch. This also means that tons of gtk code that is basically only used for supporting gtk themes can be scrapped, which would also help with porting to gtk5 or even pure wayland. Maybe upstreams gtk4 will add something later for inspecting css globally? Something like: gtk_css_provider_get_css_property("button", "color"). But for now you can get any theme you want as long as it's adwaita. :)

A little status update. Ok, I'm finally done with the key event stuff now. So just want to explain how I changed the use of the incoming events as the old way didn't work out. It's pretty simple now. First I create a list for the event queue:
nsTArray<GdkKeyEvent*> mEvents;
And then I just put the original incoming key events from the main window directly into the list:
mEvents.AppendElement(aEvent);
And when they have been processed they're removed like this:

mEvents.RemoveElementAt(index);
gdk_event_unref(GDK_EVENT(aEvent));

I have no idea if this will work out but it at least builds. And all of the key event stuff is converted over to the new gtk4 scheme with only using method calls. Yesterday I was porting tons of code but today I got stuck a bit with the mozcontainer. So there are many problems with the mozcontainer. Not only is gtkcontainer gone also gdkwindow is renamed to gdksurface and is quite a bit different. Also gtkwidget is different in gtk4. The gtk3 port is using gtk_widget_set_window to set a gdkwindow in the mozcontainer but all of that is completely gone in gtk4. So the bottom line is that basically all of mozcontainer must be reworked. I'm not in a position to deal with this right now, better just get on with the porting instead, so I'll just leave this completely broken for now. The good news is that this is not a big code, only a few hundred lines here and there, always look at the bright side of life. :) All those that want to be first with a screenshot of the gtk4 port can start thinking of this already!!

So what I think is left now to port is the main window and the theme stuff. And I don't think that this will cause too much problems. The main window is probably a pretty normal gtkwindow and already ported a few hundred lines in it and it's been mostly reformatting this far. And the theme stuff is basically only to get rid of gtkstylecontext and hardcode a default theme. So I think I'm beginning to see a little light in the end of the tunnel now. There is still hope! :) I had to put "drag and drop" on the todo list too as it almost set a new record in throwing build errors effing hell!! There must be a big change in the dnd api in gtk4 so I just disable it for now.

After almost a week of pretty hard work (been on a serious porting roll if I may say so myself :)) I finally managed to get rid of all the old native theme stuff jesus!! We're talking about many thousands of lines of code that are basically a quite insane workaround all of it. I actually think that the community edition will cut both startup time and memory consumption in half!! :) So I ended up putting a hardcoded default theme here in the header:
https://github.com/xerxes2/gecko-dev/blob/5e08c5ad2770546e03e77952b1f7c5302a4e18f2/widget/gtk4/nsLookAndFeel.h#L16

And then I use a few structs to pick them up here:
https://github.com/xerxes2/gecko-dev/blob/5e08c5ad2770546e03e77952b1f7c5302a4e18f2/widget/gtk4/nsLookAndFeel.cpp#L1429

I have no idea if this will work but it is at least building so I'm happy for now and am moving on to the main window again. I decided to use gdk_rgba_parse for encoding the colors but it is also possible to directly hardcode native mozilla rgba values but I don't think that is extremely user friendly. I have also tried to prepare already for supporting multiple hardcoded themes if that should ever be necessary.

So while sitting here just feeling good about myself I started thinking a bit of the yin-yang extension. So they will get the hardcoded default theme if they are using "system theme auto". But what they should do, if not done already, is to make it possible to manually set what day/night themes to use. If this is not possible to implement in the gtk3 port I'm pretty sure of that it will be made possible in the community edition. This way everybody is happy!! :)

Hello Jens thanks for all your hard work. I tried porting Firefox Wayland to a non-GTK native Wayland backend but I have stopped because the curve was too steep.

I have worked a lot on nsWindow.cpp and MozContainerWayland.cpp and I confirm it's the "heart" of the work.

If you get stuck, don't hesitate to ask, maybe I can help.

So I made a commit just now. I am now on line 4279 of 9985 in the main window. And since yesterday i have not got a single error outside of the main window. So far no big issues but there are a lot of them. Not so much control of windows in gtk4 it seems, probably just given up and let the compositor deal with it instead. But as I said earlier the mozcontainer needs a complete rewrite, the house has basically burned down to the ground. The gtk3 mozcontainer is actually quite simple and use off the shelf gtk3 stuff. But all of that is completely gone in gtk4 and how the heck should you figure this out?? It's not that many lines of code though. But then again, E=mc2 is not that long either. It's the figuring out part that is the problem. :)

Made one more commit just now and I have now finally found the main window. :) And as I suspected it is just a normal plain gtkwindow. And the mozcontainer is then gonna be set with gtk_window_set_child. So if someone would "just" figure out how to rewrite the mozcontainer this little bad boy will hopefully soon be up and running!! Am on line 6349 now in the main window and still no errors outside of it. One thing just now was a bit weird though, both EventControllerFocus and EventControllerMotion got enter/leave signals?? Maybe I'm missing something (got hardly any blood left in my body :)) but I disabled the focus event for now. Still a few thousand lines left to fix but I'm getting there.

Time for sitrep again. Hit a bit of a snag with events so had to rename all of them to just plain gdkevent to make it build, hoping it doesn't matter. Am now on line 8176 in the main window and going a bit slow. Was quite some time since I coded this much native code, mostly just using python, but I'm starting to learn a bit more about c++ namespaces now so trying to speed things up. The main window got tons of old bugfixes and tweaks in it that I don't think are needed anymore. After the dust has settled a bit there must be a big cleanup operation (basically line by line) of the main window initiated asap. And start working on the brand new gtk4 mozcontainer if you haven't already!! :)

MozContainer may be reduced as we moved things to WaylandSurface (Bug 1934497).
Also did you consider to port directly to Gtk 5? I have no idea of state of it, but promises Wayland only environment which may clean up things.

(In reply to Martin StrΓ‘nskΓ½ [:stransky] (ni? me) from comment #132)

MozContainer may be reduced as we moved things to WaylandSurface (Bug 1934497).
Also did you consider to port directly to Gtk 5? I have no idea of state of it, but promises Wayland only environment which may clean up things.

By the looks of it I'm almost done with porting to gtk4 (at least make it build) but I have left the mozcontainer completely broken for now as I have no idea of how to rewrite it to work on gtk4. I no nothing of gtk5 or what the plans are for it no, more than deprecating X11. So the big problem right now for the community edition is to port the mozcontainer over to gtk4. I have only ported to wayland this far so all X11 specific code is just left untouched. So it's only the wayland mozcontainer that is of top priority.

MozContainer was used in gtk2 to hold widgets with GdkWindow only. We removed that from Gtk3 port so MozContainer may be replaced by any other widget which has GdkWindow (like drawing area or just GtkWindow?). It's only needed to get GdkWindow from it as we use two GdkWindows (mShell is toplevel with CSD and MozContainer is child GdkWindow where we paint). It may be even possible to remove MozContainer and attach child GdkWindow (former MozContainer one) directly to mShell GdkWindow.

GTK4 has no child windows. (Tehnically it doesn't even have "windows" because we renamed "GdkWindow" to "GdkSurface".) There are only 2 types of GDK surfaces remaining: Toplevels and popups.

(In reply to Benjamin Otte from comment #135)

GTK4 has no child windows. (Tehnically it doesn't even have "windows" because we renamed "GdkWindow" to "GdkSurface".) There are only 2 types of GDK surfaces remaining: Toplevels and popups.

Then WaylandSurface needs to be attached directly to wl_surface provided by toplevel mShell widget.

Oh god I love you guys. Continue giving out breadcrumbs but don't give away the whole goose just yet. The game will soon be on for showing the first screenshot of the gtk4 community edition!! :) I have most likely left "a few" bugs behind that must be fixed before it'll start though. Probability of that is like 99.99% as it's impossible to know if something works without beeing able to test it. Everything will be sorted out in due time.

Note that one of the big issues with the gtk3 version of Firefox on Wayland is the fact that Firefox renders its UI in a wayland subsurface, rather than into the window surface itself. This is one of the (several) hangups holding back support for native fractional scaling in Firefox on Wayland - there is no way to correctly position and size a subsurface so that it aligns correctly with the pixels on the screen, so the result will often be blurry.

You will want to have Firefox's code render to … something? … which can be used as a GdkPaintable and therefore can be composited directly into the window by Gtk4's renderer. There's a variety of options here, but I'd recommend seeing if you can use a DMA-Buf texture which is the best way in Linux of getting a GPU texture across rendering API (gtk normally uses Vulkan, not OpenGL!) or process boundaries.

(In reply to Calvin Walton from comment #138)

Note that one of the big issues with the gtk3 version of Firefox on Wayland is the fact that Firefox renders its UI in a wayland subsurface, rather than into the window surface itself. This is one of the (several) hangups holding back support for native fractional scaling in Firefox on Wayland - there is no way to correctly position and size a subsurface so that it aligns correctly with the pixels on the screen, so the result will often be blurry.

Subsurfaces, pixel alignment or fractional scaling or blurry output are different and independent issues.

You will want to have Firefox's code render to … something? … which can be used as a GdkPaintable and therefore can be composited directly into the window by Gtk4's renderer. There's a variety of options here, but I'd recommend seeing if you can use a DMA-Buf texture which is the best way in Linux of getting a GPU texture across rendering API (gtk normally uses Vulkan, not OpenGL!) or process boundaries.

AFAIK even Gtk uses subsurfaces for GtkGraphicsOffload. Firefox will implement similar mechanism for HDR playback (Bug 1642854) where dmabuf is directly send to compositor as wl_buffer which allows direct composition of video/webgl and natively supports fractional scaling (it doesn't matter how do you paint to dmabuf, if you use va-api, gl, vulkan ...).

(In reply to Jens Persson from comment #137)

Oh god I love you guys. Continue giving out breadcrumbs but don't give away the whole goose just yet. The game will soon be on for showing the first screenshot of the gtk4 community edition!! :) I have most likely left "a few" bugs behind that must be fixed before it'll start though. Probability of that is like 99.99% as it's impossible to know if something works without beeing able to test it. Everything will be sorted out in due time.

I don't understand the breadcrumbs&goose meaning (sorry, not a native speaker). What I mean is that there are changes underway which may make Gtk4 port (or any other) easier as we're moving things away from MozContainer.

Okidoki, it finally builds all the way through, the main window was the last thing standing, but ... the linker found a few (basically 3) problems. And one of them (1) drives me absolutely nuts!! But one of them (3) I will just get rid of for now and deal with later.

  1. This problem is about a mozilla macro called MOZ_EXPORT. What it does is to set the attribute "visibility default" for the compiler to use, but 4 wayland functions give errors whatever I friggin try. It's these commented out lines here:
    https://github.com/xerxes2/gecko-dev/blob/8f8192e7b4e798eb48612b27aba752a7b84a2186/widget/gtk4/mozwayland/mozwayland.c#L214

Compiler error is this:

/home/xerxes2/tmp/gecko-dev/widget/gtk4/mozwayland/mozwayland.c:215:1: error: visibility does not match previous declaration
 0:02.70   215 | MOZ_EXPORT struct wl_compositor* gdk_wayland_display_get_wl_compositor(
 0:02.70       | ^
 0:02.70 /home/xerxes2/tmp/gecko-dev/ff-opt-obj/dist/include/mozilla/Types.h:44:39: note: expanded from macro 'MOZ_EXPORT'
 0:02.71    44 | #    define MOZ_EXPORT __attribute__((visibility("default")))
 0:02.71       |                                       ^
 0:02.71 /home/xerxes2/tmp/gecko-dev/config/gcc_hidden.h:6:13: note: previous attribute is here
 0:02.71     6 | #pragma GCC visibility push(hidden)

And the linker problem is this:
/usr/bin/ld.gold: error: hidden symbol 'gdk_wayland_display_get_wl_compositor' is not defined locally

If I leave them in the compiler complains and if I comment them out the linker complains. :( I'm completely stuck with this problem!!

  1. So the native theme stuff came back to haunt me. It seems that I only fixed the colors before and there are also sizes and possibly some drawing that is pulled in through the backdoor by widget/Theme.cpp. I guess this makes sense as they must support multiple platforms. So basically I have 2 questions, can I somehow disable native rendering for now? It's widget/gtk4/nsNativeThemeGTK.cpp that gets pulled in. And the other question is related to this, the main window is asking for "decoration size" for CSD. I'm guessing this must be something for the headerbar. I could of course hardcode a few sizes myself but this got me thinking that Firefox must have a few hardcoded sizes tucked away somewhere as fallback. Could I use already default sizes or should I just hardcode a few myself?

  2. And the final problem is about events and this can wait until it actually starts. But there is code in the main window that creates, copies and puts events and this is not possible in gtk4 afaik. Methods like gdk_event_copy/gdk_event_put don't exist in gtk4. I'm not even sure if this code is still in use but we will hopefully soon find out if mouse input works? :) For now I'm just getting rid of (comment out :)) the problems and put them on the (ever growing) todo list. And as I said before, a huge spring cleaning is needed of the main window.

(In reply to Calvin Walton from comment #138)

Note that one of the big issues with the gtk3 version of Firefox on Wayland is the fact that Firefox renders its UI in a wayland subsurface, rather than into the window surface itself. This is one of the (several) hangups holding back support for native fractional scaling in Firefox on Wayland - there is no way to correctly position and size a subsurface so that it aligns correctly with the pixels on the screen, so the result will often be blurry.

You will want to have Firefox's code render to … something? … which can be used as a GdkPaintable and therefore can be composited directly into the window by Gtk4's renderer. There's a variety of options here, but I'd recommend seeing if you can use a DMA-Buf texture which is the best way in Linux of getting a GPU texture across rendering API (gtk normally uses Vulkan, not OpenGL!) or process boundaries.

A few problems with the building still exist but hopefully soon they will be sorted out and then the mozcontainer must be fixed somehow. So I took a sneak peak at the gtk3 port now and in the bottom of the mozconatiner there is a subclass of gtkcontainer. This could possibly be replaced by a plain gtkwidget in gtk4. But in gtk3 they're using gtk_widget_get_window which does not seem possible to do in gtk4.
https://github.com/xerxes2/gecko-dev/blob/8f8192e7b4e798eb48612b27aba752a7b84a2186/widget/gtk/MozContainerWayland.cpp#L94

The mozcontainer code is not that big in lines but I'd say that it is very difficult!! And now when it looks like it must get a real makeover it's not that easy to figure out. A paintable would work fine I think as that could just be put into a gtkpicture directly.

(In reply to Martin StrΓ‘nskΓ½ [:stransky] (ni? me) from comment #140)

(In reply to Jens Persson from comment #137)
I don't understand the breadcrumbs&goose meaning (sorry, not a native speaker). What I mean is that there are changes underway which may make Gtk4 port (or any other) easier as we're moving things away from MozContainer.

Yeah a few problems with the building showed up but they will hopefully soon be fixed and then we can see what to do about the mozcontainer stuff? Making it simpler sounds pretty good to me! :)

(In reply to Jens Persson from comment #141)

And the linker problem is this:
/usr/bin/ld.gold: error: hidden symbol 'gdk_wayland_display_get_wl_compositor' is not defined locally

If I leave them in the compiler complains and if I comment them out the linker complains. :( I'm completely stuck with this problem!!

You probably want to check config/system-headers.mozbuild and add some headers to system_headers.

(In reply to Thinker Li [:sinker] from comment #143)

(In reply to Jens Persson from comment #141)

You probably want to check config/system-headers.mozbuild and add some headers to system_headers.

Hmm, you may be onto something here. The main gdk wayland header did move to the subdir in gtk4 so the path is wrong here:
https://github.com/xerxes2/gecko-dev/blob/8f8192e7b4e798eb48612b27aba752a7b84a2186/config/system-headers.mozbuild#L307

By just switching to the new path it didn't work but I'm rebuilding everything from scratch also now to see if it'll solve the problem.

(In reply to Thinker Li [:sinker] from comment #143)

(In reply to Jens Persson from comment #141)

You probably want to check config/system-headers.mozbuild and add some headers to system_headers.

You sir is an effing genious!! My computer crashed during the first rebuild so had to make a hard reboot but I rebuilt everything from scratch now and this friggin annoying problem went away!! For this alone you will get a free feature that will be implemented in the community edition. :) So problem number one on the list is fixed.

So I tried to disable the native theme stuff for now, added a method for setting csd size, fixed is_mouse_in_window (quite good stuff here in gtk4 actually) and shut up the other event errors. And now I can officially say that the gtk4 port builds. :)

To view a profile of the build, run |mach resource-usage|.
 0:51.76 Your build was successful!
To take your build for a test drive, run: |mach run|

So now phase 2 can begin, make it start. So we have 2 suggestions this far for fixing the issues with the gtk3 mozcontainer.

  1. Put Firefox' rendering engine directly into the main window.
  2. Retire the mozcontainer and replace it with a mozpaintable instead, which can be put in a gtkpicture.

Either way the game is on!! Place your bets for who will be the first to make it start. I have a few items (theme stuff mostly) on my todo list to fix that might get in the way of it starting so I'll give you a few days head start! :)

Just a small update. So yesterday I went down a rabbit hole reading up on low-level C memory management. Had a problem with the hardcoded theme. Doing it in python would take 2 minutes but doing it in c took me friggin 2 days!! But I have fixed and cleaned up the hardcoded "sort of" native theme support now. Then I suddenly realized that I have removed all of gtk from it except for gdkrgba so it would work in gtk3 too. Said and done I took it out for a spin in the gtk3 port and there was directly a build error which is my own fault. I got tired of porting all those "IsComposited" so I put one in the screenhelper. But after fixing that feature the gtk3 port did of course not start. And the debug output got no clues either where the bug was. So I started sniffing around and found out about the "adress sanitizer" but I couldn't get it to work. Had to test around 10 different combinations of build options until it finally worked!! :)

So it was only one bug that got in the way of the gtk3 port starting. And then sudddenly all of it worked!! Many colors in the hardcoded default theme were in the wrong places but it did friggin work. Firefox uses the light/dark switch from Gnome control center and it does friggin work!! :) There is only one little problem with a potential memleak but how often does people switch between light and dark anyway?? It's a pointer to the theme structs so I don't think it's a leak but I'm not completely sure. Anyway, so now nslookandfeel can be considered done for now. Only one problem left now to fix with the native theme stuff and it's the file that deals with sizes and the drawing. I will only try to completely silence it and if the gtk3 port looks ok-ish with all native drawing disabled then I will consider basic initial native theme support for the gtk4 port done.

The sad news in all of this is of course that if you would want to implement full support for native system wide gtk themes for the gtk4 port you will have to start over from scratch. Submitting patches to gtk4 upstreams for inspecting the css globally or parse the raw css code yourself may be possible in the future? But for now there is only the hardcoded fallback theme for a native look. When I'm done with the theme stuff we will try to solve the problem with the mozcontainer. I will most likely need some (a lot :)) guidance here to get it sorted out though, but we'll cross that bridge when we get there. :)

so I managed to sort out the theme stuff now and test it in the gtk3 port. And it looks just about the same as with the native drawing enabled, only a few pixels here and there seems to differ. And when I thought I that I was finally done I noticed that the friggin window close button was missing arrgh!! So I went looking for it but was just going to end up in yet another rabbit hole so I leave it for now and put it on the todo list instead. I don't know why Firefox does not add its own close button if a native one is missing?

So with that out of the way I started looking a bit more on how the gtk3 port does its drawing. I have only looked a few minutes on it now but there is a mozwaylandsurface that seems to do most of the heavylifting. And that surface is then placed into the mozcontainer, either on top of the gtkcontainer's own surface or replacing it? I haven't found the exact lines yet that does it. So if its possible to place that mozwaylandsurface directly into the main window somehow we will soon be in business!! :)

(In reply to Jens Persson from comment #148)

And when I thought I that I was finally done I noticed that the friggin window close button was missing arrgh!! So I went looking for it but was just going to end up in yet another rabbit hole so I leave it for now and put it on the todo list instead. I don't know why Firefox does not add its own close button if a native one is missing?

You should just have this made unconditional fwiw. But of course they right now look like windows buttons mostly.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #149)

(In reply to Jens Persson from comment #148)

And when I thought I that I was finally done I noticed that the friggin window close button was missing arrgh!! So I went looking for it but was just going to end up in yet another rabbit hole so I leave it for now and put it on the todo list instead. I don't know why Firefox does not add its own close button if a native one is missing?

You should just have this made unconditional fwiw. But of course they right now look like windows buttons mostly.

Yeah I forgot to test earlier with the builtin themes but did it now and it does appear a close button with a red hover color. :) I will see if I can make it work? But I went ahead and commited what I have now and in the end I ended up getting rid of gdkrgba and hardcoded native mozilla nscolors instead.
https://github.com/xerxes2/gecko-dev/blob/93fd97f23354d8cbf868262e87295e84436b8384/widget/gtk4/nsLookAndFeel.h#L16

And I added a struct pointer as class variable to switch between light/dark, must be checked if leaking by c expert. And in the end it became really pretty if I may say so myself.
https://github.com/xerxes2/gecko-dev/blob/93fd97f23354d8cbf868262e87295e84436b8384/widget/gtk4/nsLookAndFeel.cpp#L1555

So now is all native drawing and picking up system wide gtk themes disabled. And everything seems to work reasonably well. I have probably looked at different versions of Adwaita (now just called Default it seems) so all colors are not perfect (or in the right place) but it looks way better than I thought it would, except for the missing close button. It'll hopefully come back some day. :)

(In reply to Emilio Cobos Álvarez (:emilio) from comment #149)

You should just have this made unconditional fwiw. But of course they right now look like windows buttons mostly.

So I tested that switch in about:config now (it's true by default) and it does only seem to work for non-native themes which is a bit odd because of its name. :) But still no close button for the native theme but it's not big problem right now. The big battle ahead will be to get this port up and running!!

What makes it conditional is the [lwtheme] in the selector, fwiw.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #152)

What makes it conditional is the [lwtheme] in the selector, fwiw.

Ahh now I get it, and it did friggin work!! :) Is this possible to fix from within the widget/gtk directory somehow? Anyway thanks for this tip and we can see how to deal with this later?

Now when I'm finished with the porting I got this bright idea that I should fix all problems with the startup right up until it hits the problem with the mozcontainer, but with limited success this far. I got stuck on the first problem and it's really weird. This small code block bugs out when calling gdk_display_get_monitors:

GdkDisplay* display = gdk_display_get_default();
if (!display) {
    printf("No Display\n");
    return 0;
}
printf("Display name: %s\n", gdk_display_get_name(display));
GListModel* monitors = gdk_display_get_monitors(display);
printf("After get_monitors\n");
guint n_monitors = g_list_model_get_n_items(monitors);
printf("After get_n_items\n");

Output is this:

Display name: wayland-0
[Parent 1465264, Main Thread] WARNING: cannot register existing type 'GdkDisplay': 'glib warning', file /home/xerxes2/tmp/gecko-dev/toolkit/xre/nsSigHandlers.cpp:201

(firefox-default:1465264): GLib-GObject-CRITICAL **: 23:45:46.416: cannot register existing type 'GdkDisplay'
[Parent 1465264, Main Thread] WARNING: cannot add private field to invalid (non-instantiatable) type '<invalid>': 'glib warning', file /home/xerxes2/tmp/gecko-dev/toolkit/xre/nsSigHandlers.cpp:201

(firefox-default:1465264): GLib-GObject-CRITICAL **: 23:45:46.416: cannot add private field to invalid (non-instantiatable) type '<invalid>'
[Parent 1465264, Main Thread] WARNING: g_once_init_leave_pointer: assertion 'result != 0' failed: 'glib warning', file /home/xerxes2/tmp/gecko-dev/toolkit/xre/nsSigHandlers.cpp:201

(firefox-default:1465264): GLib-CRITICAL **: 23:45:46.416: g_once_init_leave_pointer: assertion 'result != 0' failed
[Parent 1465264, Main Thread] WARNING: gdk_display_get_monitors: assertion 'GDK_IS_DISPLAY (self)' failed: 'glib warning', file /home/xerxes2/tmp/gecko-dev/toolkit/xre/nsSigHandlers.cpp:201

(firefox-default:1465264): Gdk-CRITICAL **: 23:45:46.416: gdk_display_get_monitors: assertion 'GDK_IS_DISPLAY (self)' failed
After get_monitors
[Parent 1465264, Main Thread] WARNING: g_list_model_get_n_items: assertion 'G_IS_LIST_MODEL (list)' failed: 'glib warning', file /home/xerxes2/tmp/gecko-dev/toolkit/xre/nsSigHandlers.cpp:201

(firefox-default:1465264): GLib-GIO-CRITICAL **: 23:45:46.416: g_list_model_get_n_items: assertion 'G_IS_LIST_MODEL (list)' failed
After get_n_items

I just tested it in a small script on the side and it works fine. I even checked gdk upstreams and couldn't find any real clues there either. It's something with that g_once_init_leave_pointer that does not work with get_monitors??

Found a similar error message from a gtk3/gtk4 mismatch and run gtk_get_major_version and it reports friggin 3!! There must be some hardcoded buildflags somewhere that screws this up. Why else would it link to gtk3 too??

Yeah so I found two places with hardcoded linker flags that pointed to gtk3 and fixed those and boom everything just work!! So now I'm back on track fixing up everything I can before it hits the broken mozcontainer. Polishing up the screenhelper a bit and testing that everything works and after that I'm already back in the main window so I don't think there is much to fix left now, except for you know what. :)

I've not have the time yet to read in more closely on mozwaylandsurface/mozcontainer but my thinking now is, mostly based on gut feelings, that if mozwaylandsurface can paint into a gtkcontainer it should be able to paint into a gtkwindow too. So my plan right now is to modify the mozcontainer and get rid of the gtkcontainer and replace it with a gtkwindow (main window) somehow. I don't know if this is possible yet but I think this is my plan a. All you seasoned gtk coders out there that want to help out should read in on the mozwaylandsurface and how to get it to paint into a gtkwindow!!

No there does not seem to be more to fix now. Only two warnings show up, one is about "glxtest" not working and the other is about missing clipboard which is mia for now. So afaict the only thing standing in the way of it starting now is to get mozwaylandsurface to render into the main window. I don't know how to do it yet but I will at least try, and hopefully others too. :)

Attached image fxgtk4first.jpg β€”

Yes there was a little teaser scrot but I ran into a final hurdle that turned out to be quite the challenge. I could make a huge post now about my adventures in getting the gtk4 up and running but I will keep it small as I'm a bit run down right now. So my first plan was to get rid of the mozcontainer completely but that started causing many problems so I swiftly turned to plan b, to keep the mozcontainer but only as a normal struct. So I just switched out the gtkcontainer for the main window (mShell) and modified the mozcontainer code to tell mozwaylandsurface to start painting to mShell instead of to the gtkcontainer. This sounds pretty simple (quite a few twist and turns :)) and it actually is but it still took me a few days to figure it out until it finally started.

So far so good, but there is one rather annoying problem still and it is that it starts only as a fixed size surface and does not move more than that it attaches to mShell coords 0,0. So mShell is just a normal gtkwindow and can be resized but mozwaylandsurface just sits there at a fixed size. One rather funny thing is that only around 10 minutes before I got it to start for the first time I by pure accident found out that I was using the signal callbacks the wrong way. So when it started for the first time both mouse and key input friggin worked!! :) That was actually quite scary depending on how big changes been done to the event system. The scroll wheel does not work properly and it crashes instantly when using the shift key but still pretty promising.

But yesterday I finally managed to find out why mozwaylandsurface is fixed size only and it's because it does not start in "egl-mode" but using a software fallback mode that does not seem to be able to resize the surface. I still have not found a way to resize it anyway. This problem may already be fixed upstreams though as the gtkcompositorwidget and a webrenderer file it's using have been updated upstreams at mozilla. I tried to update just those files but the webrender file asks for a "glean" header (mozilla/glean/GfxMetrics.h) that does not seem to exist in my code that has not been synced to upstreams since I started the porting.

So I'm a bit stuck right now in this fixed size window software fallback mode. But I think that I will clean up my code a bit now, make some commits and then maybe I have to try to sync to upstreams?! So all and all pretty good news but still one big showstopper to fix with this friggin "egl-mode". :)

Attached image fxgtk4fixedsize.jpg β€”

So that is how it looks like in maximized mode. MShell does maximize but mozwaylandsurface just cruises on in the same size no matter what. Oh yeah forgot to say earlier, it does work to switch between light/dark themes. :) A huge hug to Emilio for telling me to just hardcode it for now!! But I have gone through both the startup and the shutdown sequence and it looks to be pretty clean already. There is one problem with the startup though that I was not planning on dealing with until it is up and running working rather well and that is the clipboard. During startup a few things ask for clipboard support, which is completely disabled for now, I managed to just bypass it for now. But still annoying because fixing mouse and key input seem more important to me than have to deal with the friggin clipboard already!! The clipboard code is not that big and is probably not gonna cause too much problems to port but will still take me a week or maybe even two to fix. But the problem with getting the egl-mode going is the really big problem right now. Chasing that sucker down is not easy and I might have to sync my code to upstreams mozilla and start working from there?!

Just relax, there will be updates later, stay tuned. :)

Thanks for sharing all your progress with such detail, it's been fascinating to follow through, and I'm impressed how quickly you've been figuring all this out!

Ladies and gents, creators of printf and ptyxis, all wankers at gtk4 upstreams for bringing motivation (just keep it coming :)), and all others that have helped out or are just interested in the community edition, we finally have lift off!! :)

So I first tried to solve the problem by getting the hardware driver working but that turned out to be a huge rabbit hole. So I took a break and went to the grocery and suddenly it just hit me that the software driver may also be egl-mode?! Maybe I was just going on about this from the completely wrong direction? Maybe I should just be looking closer to home? And how effing stupid can you be?? Maybe it is so simple that there is a resize callback set on the main window or possibly the mozcontainer? And of course it was. So hooking up the gdksurface layout signal and brushing up the DispatchResized method a bit it just worked straight away!!

Now I just need to clean up the code a bit and commit what I got so far. And after that I can get on with the porting again. I'm thinking of maybe fixing the issue with it instantly crashing when hitting the shift key? Or maybe the community edition should stay lower case only?? :) I have said before that this will be a bumpy ride, but I can promise that it will of course be much fun. After I have commited something that starts more people can start joining in on the action. Don't be afraid, tons of stuff to fix!!

(In reply to Hugo Osvaldo Barrera from comment #163)

Thanks for sharing all your progress with such detail, it's been fascinating to follow through, and I'm impressed how quickly you've been figuring all this out!

Thanks man, I do try to write a bit entertaining, it's called community edition for a reaon right?! :) But I could write much more but this bugzilla system does not seem to have a pager for the comments. Will soon need a part 2 I think?!

Ok, so I went ahead and commited everything I got now so my fx github repo should start now. It still is exactly as it was when it first started, only thing I fixed this far is the resizing error. So it is a pretty big moment in the history of firefox to see in what shape the gtk4 port was the first time it started. Software rendering is a tad slow yes but I happily take it for now! :)

But to sum things up a bit I must say that I have a huge respect for the people that wrote fx' wayland backend!! In the end the only things I have heavily modified is the main window and the mozcontainer. Everything else of the wayland backend is just ported, basically just renaming, and otherwise left untouched. So I was very lucky also that the wayland backend just continues to work even with such a big upgrade as gtk4 is. I would've been in completely over my head if the wayland backend would've needed heavy modifications.

But now the fun part starts when you can actually see what da heck you're doing! Must start porting the clipboard but think it'll be pretty easy. I have a gut feeling though that drag and drop will be a total friggin nightmare to fix, and there is a lot of it. Would not even make any promises for this year for that to start working properly. But it's still early days so we'll se how it goes?

If there are any parts of your port that you feel would already be useful to upstream, feel free to do so and put patches here/ask for review, it might make the task of merging back and forth easier?

(In reply to Gian-Carlo Pascutto [:gcp] from comment #167)

If there are any parts of your port that you feel would already be useful to upstream, feel free to do so and put patches here/ask for review, it might make the task of merging back and forth easier?

I'm not sure what you mean? Not much, if anything, of what I've done this far is useful for the gtk3 port. I'd love to have a build switch for the gtk4 port and allow to use "ifdef MOZ_GTK4". If Mozilla upstreams is ready to add a build switch for the gtk4 port just say so and I'll be ready!! :) I did fix the gdk keys so that they work in gtk4 too but the old ones work fine in gtk3 so I'd not consider that to be that useful to the gtk3 port. But if there will be, or even just investigating it, support for a build switch for gtk4 I'm more than ready to assist in that.

Otherwise I've only ported to gtk4 so I don't think I've done anything that would be useful for the gtk3 port. Support for a build switch for gtk4 would be a dream come true because as you say until that happens syncing to upstreams is a real pita and the gtk4 port is basically just a proof of concept.

Not much, if anything, of what I've done this far is useful for the gtk3 port.

Doesn't the Gtk 3 backend use any deprecated APIs for which the replacement is available both in Gtk 3 and Gtk 4? Replacing that, if possible, might be a good first step.

(In reply to LaurenΘ›iu Nicola from comment #169)

Not much, if anything, of what I've done this far is useful for the gtk3 port.

Doesn't the Gtk 3 backend use any deprecated APIs for which the replacement is available both in Gtk 3 and Gtk 4? Replacing that, if possible, might be a good first step.

It does, but upstreams gtk3 has been in maintenance mode for years already and afaik is only fixing bugs and not adding/removing stuff. Doing that would've been a good first step ta start with a few years ago but now I've already ported most of it so I think it would be a waste of time messing with the gtk3 port if it just work fine as it is. It is basically one of those if it works don't try to fix it cases. :) But sure a few years ago it would've been a nice first step to get rid of all deprecated stuff in the gtk3 port but now I think it's too late maybe?! I friggin love the gtk3 port as it is I just don't want it to stay there forever!

Just to sum things up a bit about what I've done outside of the widget/gtk4 directory. The only big thing I can think of is the gtk icon decoder that was so outdated that I went ahead and got rid of all deprecated stuff in it and it should now be a dropin replacement for the gtk3 port too. It does contain "ifdef MOZ_GTK4" though otherwise it would not work for the gtk4 port. But the current one will most likely continue to work fine in the gtk3 port forever so not really an improvement.

https://github.com/xerxes2/gecko-dev/blob/master/image/decoders/icon/gtk/nsIconChannel.cpp

And the gdk key names must start with GDK_KEY in gtk4, but again the current ones will most likely continue to work fine in the gtk3 port forever.

https://github.com/xerxes2/gecko-dev/blob/master/widget/NativeKeyToDOMKeyName.h

Outside of those 2 things it's basically just small (1-10 lines) changes needed here and there, outside of widget/gtk4, to get the gtk4 port up and running. Many are just one liners like ie gtk_init takes no arguments in gtk4. And fx got a really good build system and it's quite easy to add support for gtk4 to it. Heck even I managed to do it! :)

Compiling on arch, the browser window opens but when the mouse crashes and I get this:

Crash Annotation GraphicsCriticalError: |[0][GFX1-]: (gnome) Wayland protocol error: proxy 7491826989a0 already has listener
(t=10.8029) [GFX1-]: (gnome) Wayland protocol error: proxy 7491826989a0 already has listener

Exiting due to channel error.

(In reply to fabrixx2 from comment #172)

> Compiling on arch, the browser window opens but when the mouse crashes and I get this:
> 
> Crash Annotation GraphicsCriticalError: |[0][GFX1-]: (gnome) Wayland protocol error: proxy 7491826989a0 already has listener
>  (t=10.8029) [GFX1-]: (gnome) Wayland protocol error: proxy 7491826989a0 already has listener
> 
> Exiting due to channel error.

I can navigate with keyboard

The steps here may be similar to Gtk2->Gtk3 transition. First we have widget/gtk3 dir along widget/gtk2 one and provided two build targets (gtk2 and gtk3) and then later we merged all to widget/gtk. I guess some code from widget/gtk3 can be used directly from gtk4 dir (like mozwayland/wayland etc).

Note that the Gtk2->Gtk3 transition supported both at runtime from the same build. This will also be necessary for Gtk4, because older systems don't have it and will need a fallback to Gtk3.

(In reply to Mike Hommey [:glandium] from comment #175)

Note that the Gtk2->Gtk3 transition supported both at runtime from the same build. This will also be necessary for Gtk4, because older systems don't have it and will need a fallback to Gtk3.

The runtime support is required to ship that by Mozilla. Distros can do Gtk4 builds only and ship that which is the first goal here I expect. That was the case with Gtk3, it was shipped/used by Fedora and then was adopted/updated by Mozilla. The same applies to Wayland/VA-API and other Linux features.

But I could write much more but this bugzilla system does not seem to have a pager for the comments.

Jens, comments can be collapsed. The button's in the top-right.

I'm not sure what you mean? Not much, if anything, of what I've done this far is useful for the gtk3 port...Outside of those 2 things it's basically just small (1-10 lines) changes needed here and there, outside of widget/gtk4, to get the gtk4 port up and running. Many are just one liners like ie gtk_init takes no arguments in gtk4.

I mean if you need to do more substantial changes in common code at some point, then we can take those, I think we'd be willing to do that even if it's only for GTK4 and the rest of the port is still ongoing, just to ease the amount of patches (or back and forth merges) the GTK4 port would have to carry.

It's Martin StrΓ‘nskΓ½'s call as the GTK maintainer, but this would generally be my preference; we similarly carry for example OpenBSD support even if our tree (probably? has anyone tried?) doesn't compile on OpenBSD outright and it's not tested in our CI - downstream has a few extra patches for that. But the more there is upstream, the easier the maintainers' job downstream is.

(In reply to fabrixx2 from comment #172)

Compiling on arch, the browser window opens but when the mouse crashes and I get this:

Crash Annotation GraphicsCriticalError: |[0][GFX1-]: (gnome) Wayland protocol error: proxy 7491826989a0 already has listener
(t=10.8029) [GFX1-]: (gnome) Wayland protocol error: proxy 7491826989a0 already has listener

Exiting due to channel error.

Thanks for testing, I did fix a few obvious bugs yesterday but I must now move on with the porting so don't expect too many noticeable improvements in the near future. Just keep testing it once in a while and hopefully there will good things happening. :)

(In reply to Mr. Beedell, Roke Julian Lockhart from comment #177)

But I could write much more but this bugzilla system does not seem to have a pager for the comments.

Jens, comments can be collapsed. The button's in the top-right.

I see, I still can't find it though, I'll keep trying, thanks for the tip.

(In reply to Martin StrΓ‘nskΓ½ [:stransky] (ni? me) from comment #174)

The steps here may be similar to Gtk2->Gtk3 transition. First we have widget/gtk3 dir along widget/gtk2 one and provided two build targets (gtk2 and gtk3) and then later we merged all to widget/gtk. I guess some code from widget/gtk3 can be used directly from gtk4 dir (like mozwayland/wayland etc).

Only a build switch for the gtk4 port would be the single biggest desktop linux event for all of 2025 already in february!! :) But sitting here thinking about what is still needed to be done in the gtk4 port I would put 3 issues as the biggest tasks ahead.

1. Popups. This is also related to upstart/shutdown sequences, bringing up the main window and all popups cleanly, fine-tuning the now stripped down mozcontainer. All of this may sound like a huge task but may not be that extremely difficult to do for someone with knowledge (not me :)). But to iron out all "quirks" with this you would need to have a pretty deep understanding of exactly how the wayland backend works.
2. Drag-and-drop. All of this is just completely disabled for now and left untouched. But my gut feeling tells me that this will be a huge task to implement properly. Maybe working fulltime one month or so just for giving an estimate. That would be my guess anyway.
3. Clipboard. Yesterday I managed to get the native keybindings going again so I will take that as a sign for me to start porting the clipboard. :) As I now can use the copy/paste clipboard hotkeys I got no excuse anymore for not doing it. This is not a small task so it will take some time.

Other than those 3 issues other things seems more easy. Pickers, crashreporter, updater and possibly a few other things I've forgot about are just small problems in comparison with the 3 big ones. On a pure technical level I'd say that 1 is the most difficult. If you're only counting hours of work it may actually be dnd that is the winner here. But I'll go ahead and port the clipboard now as I think I can manage it. So far my level of porting has been beyond insane!! I'm actually quite shocked myself. :) I do have some questions still about some memory management but it'll be sorted out eventually.

(In reply to Gian-Carlo Pascutto [:gcp] from comment #178)

I'm not sure what you mean? Not much, if anything, of what I've done this far is useful for the gtk3 port...Outside of those 2 things it's basically just small (1-10 lines) changes needed here and there, outside of widget/gtk4, to get the gtk4 port up and running. Many are just one liners like ie gtk_init takes no arguments in gtk4.

I mean if you need to do more substantial changes in common code at some point, then we can take those, I think we'd be willing to do that even if it's only for GTK4 and the rest of the port is still ongoing, just to ease the amount of patches (or back and forth merges) the GTK4 port would have to carry.

It's Martin StrΓ‘nskΓ½'s call as the GTK maintainer, but this would generally be my preference; we similarly carry for example OpenBSD support even if our tree (probably? has anyone tried?) doesn't compile on OpenBSD outright and it's not tested in our CI - downstream has a few extra patches for that. But the more there is upstream, the easier the maintainers' job downstream is.

I see, yes I do remember seeing openbsd in the code somewhere now when you're mentioning it. I don't have any more plans on changing any code outside of widget/gtk4 right now. I can't remember right now how many places would need to have ifdef MOZ_GTK4 but if I'd guess it's around 50-100 (most of them just oneliners-ish). But I'm not going outside of widget/gtk4 if I absolutely not have to so I can't remember. If Stransky is the head honcho of the gtk ports at mozilla I'll just happily follow his lead. I'm just a hobby coder that kinda just stumbled into this porting business. :)

And one more thing that I've been starting thinking about lately is security. I'm a real person and using my real name here. Yes I may come off as a bit of a wild card most of the time and I guess I am but just wanna say that I'm still 100% trustworthy. And so far all code in my github is all me. I can't remember getting any code from anyone else so far at least. We don't want any security breach in fx thank you very much!! Would be the total jackpot for any shady government agency. But so far the community edition is all on little old me. :)

Just a little update on the clipboard work. It turned out to be really difficult. it's a completely new clipboard api in gtk4 but I already knew that so it was no surprise. I have used filepicker and gtksourceview before so I already know how those async open/finish operations work. But there is something called "targets" in gtk3 that is completely missing in gtk4. So the gtk4 clipboard will need a partial rewrite at least. This turned out to be so difficult so I must split up the work in stages. So first I will make it build, around 80% done now, and secondly I'll make the clipboard service work again and at least report that clipboard support is available. Firefox does not even start without clipboard support, I had to cheat and comment out a few code blocks just to make it start.

It may be that targets is called formats in gtk4 but I'm not really sure yet. So this turned out to be a real challenge. Thankfully it is not that many lines of code it's just difficult (well, different from gtk3). I will hopefully be able to at least test the text clipboard with the hotkeys from a text entry. But even getting the text clipboard to work would almost take a miracle as it looks right now! :) Again, thank god it 's not that many lines of code otherwise this would've taken me forever!

Ok, so I finally managed to get the clipboard to build. And after that it took me an hour to get it to link properly. And after that it took me 30 friggin minutes just to find all places where I had previously disabled it. Had to commit 11 files in total. But after sorting all that out the clipboard service worked straight away. Well, it is reporting that clipboard support is available so the gtk4 port now starts without having to cheat at least. So phase 1 of the clipboard work is now completed.

In phase 2 I'll try to get the text clipboard working and it is actually beginning to look like I might pull it off! :) The sidekick files (nsClipboardWayland, AsyncGtkClipboardRequest) are just fine as they are and fairly easy to port but the main clipboard file is a complete trainwreck and in dire need of a complete rewrite. And rewriting from scratch in c++ is not exactly my speciality. But I will do my best to at least get text clipboard working. If I manage that I think it's fair to say that clipboard support is around 50% done.

The gtk3 port uses a gtktextview to decode hotkeys but that trick does not seem to work in gtk4 so I think I'll just go ahead and hardcode the same hotkeys (c,x,v) as gnome-text-editor uses and use them to test if text clipboard is actually working. But there are still "a few" problems to solve with the data clipboard and the "targets" (still don't know what da heck it is). But all and all it is starting to look like some progress in the right direction wit regards to the clipboard. :)

The community edition proudly presents support for text clipboard (only with hotkeys for now). :) But man I had to dig really deep to find the 180+ iq level needed to figure this all out!! It is not the gtk4 clipboard that is the problem it's the old one, but I've finally figured most of it out now. All I can say is that the upstreams gtk4 clipboard implementation is far superior to the old one. Well, as it should be when they ditched everything and rewrote it from scratch. There will be a huge cleanup operation needed in the main clipboard file when the dust has settled. I've already begun to comment out huge code blocks and more incoming. Fx' gtk4 clipboard will be far easier to maintain longterm also. Still a few things to figure out with the data clipboard but first I must fix the right-click menu.

Hi Jens,
Great job! I do check your progress almost everyday. It is a super exciting project.

Just to remind you. You haven't rebase your branch for a while. Please rebase your branch if possible. That would make it easier to merge to the upstream later.

Not entirely sure if this is the case here, but the concept of "targets/formats" which regards to clipboards sounds like mime-types.

Keep in mind that when applications take a selection, they might be offering text/plan, text/html, image/png, or a plethora of other formats.

I'm not familiar with GTK lingo, so the naming simply gives me an impression that this might be it. If you a bit of a higher level guide to the clipboard and its working, I wrote a short article on that a while ago: https://whynothugo.nl/journal/2022/10/21/how-the-clipboard-works/

BTW: drag and drop uses basically the same concepts (e.g.: a data offer can have multiple mime-types in the same way).

(In reply to Thinker Li [:sinker] from comment #186)

Hi Jens,
Great job! I do check your progress almost everyday. It is a super exciting project.

Just to remind you. You haven't rebase your branch for a while. Please rebase your branch if possible. That would make it easier to merge to the upstream later.

I have not yet rebased to upstreams mozilla since I started porting. I'm afraid it'll cause me a lot of small (and possibly a few big) problems that will just slow me down. I could probably fix all problems myself except when it comes to problems with the wayland backend. And that is what I'm afraid of. I don't even know how rebasing works with regards to all my changes (I don't even know how many they are??) to code outside of widget/gtk4. But if mozilla will not (ever??) add a build switch for the gtk4 port I will (well, must I guess) eventually rebase everything. But don't forget to wake me up if mozilla do add a build switch so I can put in second gear!! :) For now it's all an uphill battle.

I put in a little request for help here. There seems to be a sort of offset for how mozwaylandsurface attaches to mShell (main window). Looks like coords -10/-10 or something. If anyone finds a solution for that don't be afraid to tell me! I have not been seriously trying to solve it myself because I'm afraid it could be another rabbit hole. :) I think it has been like that ever since the resizing problem got fixed, could be a clue.

(In reply to Hugo Osvaldo Barrera from comment #187)

Not entirely sure if this is the case here, but the concept of "targets/formats" which regards to clipboards sounds like mime-types.

Keep in mind that when applications take a selection, they might be offering text/plan, text/html, image/png, or a plethora of other formats.

I'm not familiar with GTK lingo, so the naming simply gives me an impression that this might be it. If you a bit of a higher level guide to the clipboard and its working, I wrote a short article on that a while ago: https://whynothugo.nl/journal/2022/10/21/how-the-clipboard-works/

BTW: drag and drop uses basically the same concepts (e.g.: a data offer can have multiple mime-types in the same way).

Thanks man. Yes it looks like (I think :)) targets in the gtk3 clipboard is only mime-types after all. But it's treated like any other data on the clipboard and that got me very confused. And there is a quite insane amount of lines in fx' gtk3 clipboard that only deals with targets. In gtk4 it's basically just 2 lines of code, one that gets formats and one that matches them:

GdkContentFormats* formats = gdk_clipboard_get_formats(clipboard);
for (auto& flavor : aFlavorList) {
  if (gdk_content_formats_contain_mime_type(formats, flavor.get())) {
    return true;
  }
}

The above code was a lot more code in gtk3 afaict. But I'm far from done with the gtk4 clipboard yet so there will most likely be some problems left to solve. One problem in the gtk4 clipboard I don't really understand is that when you're only reading data you should use a GInputStream object. But that object does not seem to have a length/size property, The length is used internally in fx when setting the data. this is the line from the gtk3 port:
mData->SetData(Span(gtk_selection_data_get_data((GtkSelectionData*)aData), dataLength));

But I've not yet started fixing the data clipboard, did not really think that I'd ever manage to fix the text clipboard even. :)

Just want to explain why the above clipboard problem may be "a thing" for me. This is how I usually work when I port fx. My plan a is to just stay within gtk (and family) as much as possible as gtk itself got superb memory management. Most of it is just pointers to objects owned by gtk (ie the GdkContentFormats* object above) that will hardly ever cause any problems. And if you do have to free something there usually is already done methods for that (destroy/unref/free). With gtk4 it's hardly any difference to code in c or python even. But if something can't be done only in gtk my plan b is to just use the same memory management as the gtk3 port does. I mean, why reinvent the wheel right?! :) You can write a text clipboard implementation in a gazillion different ways but in the end you will most likely end up with a string object. Then I can just put the string object in the same place as the gtk3 port does, which is what I did. Plan a or b works out basically 99% of the time. It's when it does not that I tend to end up in more trouble as a more managed language oriented coder. Mozilla does also got it's own string implementation which is really nice and helps a lot.

Dammit, I was just going to fix the right-click menu so that I could finish the work on the clipboard but as it turns out it's not gtk. Even the friggin right-click menu is fx' own stuff so now I have to figure this out before I can finish the clipboard. The popups are gtkwindow popups in the gtk3 port but in gtk4 there is only one gtkwindow (toplevel I guess) and the closest thing I can find as replacement in gtk4 is gtkpopover. These are only gtkwidget and not gtkwindow though so pretty big changes needed to the main window to sort all this out. I have used gtkpopover before and I think that set_parent must be the replacement for set_transient.

I've done some initial testing now and it shows some small promise but the popup issue was number 1 on my hard items todo list for a reason!! :) And I'm pretty run down now after bringing my a game to be able to fix the clipboard so now I must regroup and reboot (again) . But this could (probably will :)) take some time to sort out, if I ever even manage. You must have an expert level of knowledge on the main window to be able to fix this so I'd say that it's a bit above my paygrade. But the good news is that there is not much else to fix now (still waiting for a white knight to show up and fix dnd :)) anyway so I will give it a go. But this is definitely one of those "don't hold your breath" kind of things.

I was just going to fix the right-click menu so that I could finish the work on the clipboard but as it turns out it's not gtk. Even the friggin right-click menu is fx' own stuff so now I have to figure this out before I can finish the clipboard.

Jens, perhaps "widget.gtk.native-context-menus": true's ≣⃣ implementation would be easier to fix than FX's custom one, since it should be native GTK3 code. Most entries aren't connected to whatever the GTK equivalent to QActions is, but it's otherwise fairly complete.

You still need custom popups for stuff like the hamburger menu tho. So that only gets you so far.

GTK4 doesn't support popups. For the hamburger menu one should use a popover instead (something like https://github.com/Taiko2k/GTK4PythonTutorial?tab=readme-ov-file#adding-a-button-with-menu.

(In reply to Mr. Beedell, Roke Julian Lockhart from comment #192)

I was just going to fix the right-click menu so that I could finish the work on the clipboard but as it turns out it's not gtk. Even the friggin right-click menu is fx' own stuff so now I have to figure this out before I can finish the clipboard.

Jens, perhaps "widget.gtk.native-context-menus": true's ≣⃣ implementation would be easier to fix than FX's custom one, since it should be native GTK3 code. Most entries aren't connected to whatever the GTK equivalent to QActions is, but it's otherwise fairly complete.

I see, thanks for the tip. I did go looking a bit for a way to revert back to the gtk menu but did not get that far. But if there is even a config option for it I guess it must be fixed anyway otherwise it should be removed. I will definitely investigate and see if I can get the gtk menu going?

(In reply to Emilio Cobos Álvarez (:emilio) from comment #193)

You still need custom popups for stuff like the hamburger menu tho. So that only gets you so far.

My initial testing with gtkpopover shows that it might work out in the end. The gtkpopover seems to be a gdksurface of type gdkpopup which would mean that mozwaylandsurface should be able to paint to it. So far gtk4 has not let me down even once and it might turn out that gtkpopover is even better to use for the popups than the gtk3 gtkwindow popups. But after this shocker I might take the evening off and just think about this for a while?! :)

(In reply to darkdragon-001 from comment #194)

GTK4 doesn't support popups. For the hamburger menu one should use a popover instead (something like https://github.com/Taiko2k/GTK4PythonTutorial?tab=readme-ov-file#adding-a-button-with-menu.

Yes but it's most likely that it's all fx' own stuff anyway. Fx' wayland backend paints basically everything nowadays and it needs a gdksurface to work. But hopefully gtkpopover works out!! I don't even know if there is a plan b?? :)

We definitely need to GdkPopup for popups as it uses xdg_popup to dynamically place popups by xdg_positioner and allows to resize the xdg_popup without map/unmap (unlike Gtk3). The actual GtkWidget over GdkPopup may be GtkPopover or a custom widget.

I can now 100% confirm that mozwaylandsurface can paint just find to the gtkpopover. I have right-click menu (and the others) up and running just fine now. But it's going to take some serious tinkering with sizing and placing all popups perfectly!! Only in early testing phase right now but yes it does look rather promising. So now all popups must be ported over to use gtkpopover and this is a pretty big job job so I must do this in stages because it's very easy to screw something up that is later hard to track down.

You could of course also write your custom gtkwidget instead of using a plain gtkpopover but a custom widget would most likely inherit both gtkwidget (needed for input events and other stuff) and gdkpopup so would work basically the same way as a gtkpopover. I will just go ahead and use a plain gtkpopover for now and then we can see if it should be switched out later. Was thinking that maintaining a custom gtkwidget may be a pita but upstreams gtk4 may not touch what is needed too much now?!

So I've been testing the gtkpopover for the popups a bit more and it seems to work just fine for positioning and sizing. But after that I got over to the themeing of it that must be removed to be able to work for fx. But as it turns out the gtkpopover doesn't like to be seen in public completely invisible. So I had to start to seriously dig into this and in the end, I almost gave friggin up, I did manage to make it show up completely invisible by using the following lines:

if (mWindowType == WindowType::TopLevel) {
  g_signal_connect(mShell, "close-request", G_CALLBACK(widget_destroy_cb), nullptr);
  GtkCssProvider* provider = gtk_css_provider_new();
  const char* default_css = "popover {background-color: rgba(0,0,0,0); border: none;} \
                             popover > contents {background-color: rgba(0,0,0,0); border: none; \
                             box-shadow: 0px 0px 0px 0px;}";
  gtk_css_provider_load_from_string(provider, default_css);
  gtk_style_context_add_provider_for_display(gdk_display_get_default(), GTK_STYLE_PROVIDER(provider),
                                             GTK_STYLE_PROVIDER_PRIORITY_APPLICATION);
}
if (mWindowType == WindowType::Popup) {
  gtk_popover_set_has_arrow(GTK_POPOVER(mShell), false);
}

In the end it was the box-shadow that did it. But man it took some serious trial and error before finding the solution. I don't even know if this is a feature or bug (I do hope it stays this way though!!)?! I will hang on a little pic to show you how it looks.

Attached image fxmenu.jpg β€”

Never thought I was gonna think a right-click menu could look that good. One of the biggest remaining technical hurdles of the gtk4 port has now been solved. A pixel-perfect and flicker-free browsing experience for the linux desktop may not be that far off now!! :) No but seriously, just to clarify, to fix all popups perfectly is more work than a comp-sci thesis ok, just saying. I have only scratched the surface yet. I have not even started working on it yet, only tested if the gtkpopover would be possible to use.

But now I think that I must first shut up the dragservice somehow because everyone and their dog seems to be missing it. It spits out so many warnings and crap that it's almost beyond comprehension and it gets in the way of debugging what you're really working on atm. The dnd stuff seems to be located to only 2 files (h and cpp) and hopefully I can get the dragservice working by basically just getting it to build. I think all dnd stuff is new in gtk4 though so it will be a lot to comment out. :) I have no plans to really fix dnd in a long time as my gut feeling tells me it is like 10 times more difficult than the clipboard to fix. One step at a time.

(In reply to Jens Persson from comment #200)

Never thought I was gonna think a right-click menu could look that good. One of the biggest remaining technical hurdles of the gtk4 port has now been solved. A pixel-perfect and flicker-free browsing experience for the linux desktop may not be that far off now!! :) No but seriously, just to clarify, to fix all popups perfectly is more work than a comp-sci thesis ok, just saying. I have only scratched the surface yet. I have not even started working on it yet, only tested if the gtkpopover would be possible to use.

But now I think that I must first shut up the dragservice somehow because everyone and their dog seems to be missing it. It spits out so many warnings and crap that it's almost beyond comprehension and it gets in the way of debugging what you're really working on atm. The dnd stuff seems to be located to only 2 files (h and cpp) and hopefully I can get the dragservice working by basically just getting it to build. I think all dnd stuff is new in gtk4 though so it will be a lot to comment out. :) I have no plans to really fix dnd in a long time as my gut feeling tells me it is like 10 times more difficult than the clipboard to fix. One step at a time.

What's left to go, what's the TODO list?

(In reply to Niko Cantero from comment #201)

(In reply to Jens Persson from comment #200)
What's left to go, what's the TODO list?
Same as mentioned before, the main window (popups, upstart/shutdown etc) and drag-and-drop. Clipboard support is mostly a cleanup operation from now on and then there are a bunch of smaller tasks that even the community can deal with. I started reading up on dnd in gtk4 but it's all a completely new api. So not extremely much left to do if you only count lines of code but it's very difficult though. Fixing the main window and dnd are basically fulltime pro jobs. There needs to be a build switch added for gtk4 too otherwise this will get nowhere and it'll just rot away on gtk3. I am basically in regrouping mode right now.

Fedora seems to get rid of rust bindings fpr gtk3. That would mean that the fx updater would no longer work. Port it to gtk4 is only a few minutes work though but would of course introduce a new dependency. Full deprecation of gtk3 will not happen until gtk5 is released though and that is most likely not happening in at least 2 years, only a guess.

https://pagure.io/fesco/issue/3380

(In reply to Jens Persson from comment #203)

Fedora seems to get rid of rust bindings fpr gtk3. That would mean that the fx updater would no longer work. Port it to gtk4 is only a few minutes work though but would of course introduce a new dependency. Full deprecation of gtk3 will not happen until gtk5 is released though and that is most likely not happening in at least 2 years, only a guess.

https://pagure.io/fesco/issue/3380

Doesn't Firefox use in-tree rust-bindings anyway?

(In reply to Jens Persson from comment #203)

Full deprecation of gtk3 will not happen until gtk5 is released though and that is most likely not happening in at least 2 years, only a guess.

This seems to happen frequently, so it's probably that English is a difficult language, but "deprecated" does not mean "deleted" or "gone"

https://www.merriam-webster.com/dictionary/deprecate

In software development, "deprecated" means that the maintainers are warning people to stop using something (maybe they plan to delete it later, or maybe there are just better ways to do something)

I kinda' wish this word didn't exist because there's a lot of confusion around its usage

(In reply to Jens Persson from comment #203)

Fedora seems to get rid of rust bindings fpr gtk3. That would mean that the fx updater would no longer work. Port it to gtk4 is only a few minutes work though but would of course introduce a new dependency. Full deprecation of gtk3 will not happen until gtk5 is released though and that is most likely not happening in at least 2 years, only a guess.

https://pagure.io/fesco/issue/3380

Still workng on this?

(In reply to Niko Cantero from comment #206)

(In reply to Jens Persson from comment #203)
Still workng on this?

No I'm not. It's just not possible for me to continue for reasons I've said before.

But, the ticket Emilio posted earlier got me a little bit curious so I've been sniffing around the bugzilla a bit. So they seem to get rid of everything but colors from the native theme stuff. This will make the gtk3 and gtk4 ports look identical if using Adwaita and only differ by colors if using other system themes. So this is good.

And I also found this ticket: https://bugzilla.mozilla.org/show_bug.cgi?id=1964046

IIRC the single biggest issue by far I had outside of widget/gtk was the icon decoder. Emilio has posted a draft of the icon decoder that fixes all the most problematic stuff ... and more. His draft looks to be even closer to gtk4 than my own, and also a bit more optimized. So if that draft lands officially it is very good news. Draft here: https://phabricator.services.mozilla.com/D247587

Maybe something is going on? Maybe Umbre... err Mozilla corp is test driving the gtk4 port in a basement somewhere? This actually makes sense as you would not want to be distracted by tons of patches and bug tickets when porting drag-and-drop and integrating the wayland backend properly into the main window. Only that is a few months hard work. :)

Maybe something is going on? Maybe Umbre... err Mozilla corp is test driving the gtk4 port in a basement somewhere?

FWIW, that's not the case. I'm just making stuff incrementally better, keeping in mind the restrictions that gtk4 will (eventually) impose and such :)

(In reply to Jens Persson from comment #207)

Maybe something is going on? Maybe Umbre... err Mozilla corp is test driving the gtk4 port in a basement somewhere? This actually makes sense as you would not want to be distracted by tons of patches and bug tickets when porting drag-and-drop and integrating the wayland backend properly into the main window. Only that is a few months hard work. :)

Occam's razor is always a good guide. All development is open and you see all progress here. AFAIK we're not working on Gtk4 as there are more pressing issues on Linux right now.

So they're denying that something is cooking, I'm not buying it though. It can't be that long now until we see some real zombies in the streets, all the signs are there! :) And in some more real news the new icon decoder has now landed at m-c and is looking really good. Looks to be basically a 1:1 api fit with gtk4, only a few name changes needed and it'll work just fine in gtk4 too. So this is really good news as the biggest problem outside of widget/gtk has now been properly and officially fixed. Instead of taking 10 days to port it'll now take 10 minutes!! Sometimes a little bit of whining does pay off. :) I think I must celebrate this by syncing my gtk4 branch to upstreams, don't know how to do it yet but I'll try to figure it out.

So one more bigger problem left to fix now outside of widget/gtk, but I think this is a non-issue really. It's the gdk key names in this file that need to get updated to the new scheme: https://github.com/mozilla/gecko-dev/blob/master/widget/NativeKeyToDOMKeyName.h

I've forgot exactly how that file works now but the macro must somehow pick up the compat header (gdkkeysyms-compat.h) otherwise they would not work. The compat header is not available in gtk4 though as I don't think they like to carry over deprecated apis to the next major gtk version. The problem with code outside of widget/gtk is that it must work with both ports if it should work to build them side by side using build switches. Anyway, the new gdk key scheme is not exactly new (14 years old): https://gitlab.gnome.org/GNOME/gtk/-/commit/913cdf3be750a1e74c09b20edf55a57f9a919fcc

I just built the gtk3 port from m-c and the new key scheme seems to work just fine. Built with this file: https://github.com/xerxes2/gecko-dev/blob/master/widget/NativeKeyToDOMKeyName.h

But I think this is a small issue compared with the icon decoder. And some new features in the icon decoder may have broken a few things here and there but this is almost all outside of gtk so all those fixes we will get for free! So I will try to sync my gtk4 branch to m-c, but don't get your hopes up just yet, still the big work with porting dnd and integrating everything properly into the main window left to do. But it can't hurt to report some good news in this ticket, baby steps still but we take what we can get. :)

If https://github.com/xerxes2/gecko-dev/blob/master/widget/NativeKeyToDOMKeyName.h also works with GTK3, can you prepare a patch to get it merged? Small patches are easier to be reviewed and more likely to land in a timely manner.

(In reply to darkdragon-001 from comment #211)

If https://github.com/xerxes2/gecko-dev/blob/master/widget/NativeKeyToDOMKeyName.h also works with GTK3, can you prepare a patch to get it merged? Small patches are easier to be reviewed and more likely to land in a timely manner.

Yeah sure I think I can manage that. But I can't seem to figure out how I should sync my repo to upstreams?? I must somehow resolve "merge conflicts", dammit. Maybe I just have to start a new repo from scratch? But it doesn't matter extremely much as I would just be stuck at porting dnd anyway.

Any ideas if the GTK4 port can help address this issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1880467

TLDR: Firefox continues rendering windows in inactive workspaces or that are invisible due to some other reason. This produces continuous CPU load rendering content that is never displayed. It seems that GTK3 doesn't properly reflect an equivalent to wl_surface::frame, so clients don't know that rendering is useless.

(In reply to Hugo Osvaldo Barrera from comment #213)

Any ideas if the GTK4 port can help address this issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1880467

TLDR: Firefox continues rendering windows in inactive workspaces or that are invisible due to some other reason. This produces continuous CPU load rendering content that is never displayed. It seems that GTK3 doesn't properly reflect an equivalent to wl_surface::frame, so clients don't know that rendering is useless.

Wayland should be fixed regardless of Gtk version, we use wl_frame directly. X11 is broken (Bug 1826291).

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: