Closed Bug 1978620 Opened 13 days ago Closed 6 days ago

firefox-141.0 doesn't start if gtk+ doesn't have wayland support

Categories

(Core :: Widget: Gtk, defect)

Firefox 141
defect

Tracking

()

RESOLVED FIXED
143 Branch
Tracking Status
firefox-esr128 --- unaffected
firefox-esr140 --- unaffected
firefox141 + fixed
firefox142 + fixed
firefox143 --- fixed

People

(Reporter: juippis, Assigned: emilio)

References

(Regression)

Details

(Keywords: regression)

Attachments

(2 files)

Steps to reproduce:

Download latest Firefox-141.0 for Linux from https://archive.mozilla.org/pub/firefox/releases/141.0/linux-x86_64/en-US/
extract and run it.

Actual results:

$ ./firefox-bin 
XPCOMGlueLoad error for file /home/gui/ff/firefox/libxul.so:
/home/gui/ff/firefox/libxul.so: undefined symbol: gdk_wayland_device_get_wl_seat
Couldn't load XPCOM.

When the system gtk+ package is built without wayland support.
gtk+ still has an option to disable wayland,
https://gitlab.gnome.org/GNOME/gtk/-/blob/main/meson.options?ref_type=heads#L12

option('wayland-backend',
       type: 'boolean',
       value: true,
       description : 'Enable the wayland gdk backend (only when building on Unix except for macOS)')

Expected results:

Firefox should launch using X11 backend instead. The previous versions had no issues with this.
--enable-default-toolkit=cairo-gtk3-x11-wayland has worked previously just fine even without wayland backend in gtk+?

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

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

Emilio, do you have any idea?
Looks like that we need a weak symbol here.

Severity: -- → S2
Flags: needinfo?(emilio)
Flags: needinfo?(emilio)
Assignee: nobody → emilio
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Status: ASSIGNED → RESOLVED
Closed: 12 days ago
Resolution: --- → FIXED
Target Milestone: --- → 143 Branch

Hey,

the patch applies to 141.0 and therefore was easy to test. Unfortunately I still couldn't get the browser to launch with this, when self-built with both X and wayland support and moved to a system where gtk+ doesn't have wayland support. 140.0.4 still seems to work fine with the test setup.

Anyway if there are more commits related to this that'll make it work, could these be backported to a .1 release, or at least to upcoming 142?

Unfortunately I still couldn't get the browser to launch with this

What is the error? I can try to somehow get a setup with x11-only GTK3 next week I guess. Thanks

Flags: needinfo?(juippis)

Indeed the error is slightly different now:

$ firefox 
XPCOMGlueLoad error for file /usr/lib64/firefox/libxul.so:
/usr/lib64/firefox/libxul.so: undefined symbol: gdk_wayland_window_set_use_custom_surface
Couldn't load XPCOM.
Flags: needinfo?(juippis)

Ok, that's another new function call that I missed. can you confirm this diff fixes it for you? I think it's the last :)

diff --git a/widget/gtk/mozwayland/mozwayland.c b/widget/gtk/mozwayland/mozwayland.c
index 28ddaa29625e..4fdc86f145a9 100644
--- a/widget/gtk/mozwayland/mozwayland.c
+++ b/widget/gtk/mozwayland/mozwayland.c
@@ -226,6 +226,9 @@ MOZ_EXPORT struct wl_surface* gdk_wayland_window_get_wl_surface(
   return NULL;
 }

+MOZ_EXPORT void gdk_wayland_window_set_use_custom_surface(
+    GdkWaylandWindow* window) {}
+
 MOZ_EXPORT struct wl_pointer* gdk_wayland_device_get_wl_pointer(
     GdkDevice* device) {
   return NULL;
Flags: needinfo?(juippis)

Now it works! :)

Thanks! Could these be backported to the next release?

(also reopening until the commit lands to the source tree and this bug can be referenced)

Status: RESOLVED → REOPENED
Flags: needinfo?(juippis)
Resolution: FIXED → ---
Flags: needinfo?(emilio)
Flags: needinfo?(emilio)
Keywords: regression
Regressed by: 1970372

Comment on attachment 9503237 [details]
Bug 1978620 - Add gdk_wayland_window_set_use_custom_surface to mozwayland too. r=stransky

Beta/Release Uplift Approval Request

  • User impact if declined/Reason for urgency: Fixes startup on some uncommon setups.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: none
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): ~zero risk, defines some symbols that are otherwise replaced for the real ones.
  • String changes made/needed: none
  • Is Android affected?: No
Attachment #9503237 - Flags: approval-mozilla-release?
Attachment #9503237 - Flags: approval-mozilla-beta?

Comment on attachment 9502291 [details]
Bug 1978620 - Add gdk_wayland_device_get_wl_seat to mozwayland. r=stransky

(See above)

Attachment #9502291 - Flags: approval-mozilla-release?
Attachment #9502291 - Flags: approval-mozilla-beta?

Set release status flags based on info from the regressing bug 1970372

Tracking for next week planned dot release.

Status: REOPENED → RESOLVED
Closed: 12 days ago6 days ago
Resolution: --- → FIXED

Comment on attachment 9502291 [details]
Bug 1978620 - Add gdk_wayland_device_get_wl_seat to mozwayland. r=stransky

Approved for 142.0b5 and 142.0b6

Attachment #9502291 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #9503237 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

Dianna, you only merged one of the two patches, right? https://hg.mozilla.org/mozilla-central/rev/03126ea2d55a is also needed

Flags: needinfo?(dsmith)

hmm my apologies not sure how i missed that

Flags: needinfo?(dsmith)
Depends on: 1980341
Attachment #9502291 - Flags: approval-mozilla-release? → approval-mozilla-release+
Attachment #9503237 - Flags: approval-mozilla-release? → approval-mozilla-release+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: