Open Bug 1701123 Opened 3 years ago Updated 1 day ago

Port Firefox to GTK4

Categories

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

Product:
Core
Component:
Widget: Gtk
Type:
enhancement

Tracking

()

People

(Reporter: malix0, Unassigned)

References

(Blocks 3 open bugs)

Details

Attachments

(1 file)

basic-config.patch
1.09 KB, patch
Details | Diff | Splinter Review

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
Priority: -- → P5

We don't have such plan yet.

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.

Flags: needinfo?(stransky)
Flags: needinfo?(stransky)

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.

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
Assignee: stransky → nobody

(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
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: