Fedora Users Now Have An Experimental Firefox Wayland Package

[microcode]

Hmm, I'm suspecting that direct-rendering programs cannot go through broadway. Or run on Wayland unless the parts relying on Xorg are rewritten.

On FIrefox the gtk+ is only for windows decoration afaik.

It's also used for input method integration in text fields(ibus and friends), context menus, buttons, checkboxes, dropdowns... a few other things. Chrome has its own native-level toolkit, but it doesn't have support for all the input method frameworks and rendering engines on their different platforms yet; so they're in a similar situation.

[JohnGalt]

I just built for openSUSE Tumbleweed from the src package (software versions should be relatively on par with fedora rawhide).

I created and used a new profile as outlined, and verified it is in fact running on wayland and not Xwayland. I also tested on gnome (wayland), sway, and weston, as well as radeonsi and amdgpu. However, all had the following issue: The window only updates on change of focus or window resize, which makes it unusable. Anyone else run into this or have ideas?

Edit: I also went into settings and disabled hw accel with no change.

Edit2: the gtk stuff (menus and whatnot) works fine without needing to resize, change focus, or move the window. The page only updates on those actions (so no change on typing or anything else).

[Luke]

I just built for openSUSE Tumbleweed from the src package (software versions should be relatively on par with fedora rawhide).

I created and used a new profile as outlined, and verified it is in fact running on wayland and not Xwayland. I also tested on gnome (wayland), sway, and weston, as well as radeonsi and amdgpu. However, all had the following issue: The window only updates on change of focus or window resize, which makes it unusable. Anyone else run into this or have ideas?

Edit: I also went into settings and disabled hw accel with no change.

Edit2: the gtk stuff (menus and whatnot) works fine without needing to resize, change focus, or move the window. The page only updates on those actions (so no change on typing or anything else).

What GTK3 version are you testing? This sounds a bit like its related to a bug in gtk 3.21.3 that was patched in master a couple days ater release. GTK devs radically changed the drawing system-and FIrefox would turn black on change of focus, updating only when each widget was moused over. I saw this in both X11 and with Xwayland with released FF47.

[JohnGalt]

What GTK3 version are you testing? This sounds a bit like its related to a bug in gtk 3.21.3 that was patched in master a couple days ater release. GTK devs radically changed the drawing system-and FIrefox would turn black on change of focus, updating only when each widget was moused over. I saw this in both X11 and with Xwayland with released FF47.

That's probably the issue. I'm on the GNOME Next repo (3.21.3), and it built using system packages through rpmbuild. I'm working on getting a successful OBS build with the wayland patches and spec changes, but not quite there yet. Currently stuck at a linking error:

 
 [ 4083s] ../../xpcom/base/Unified_cpp_xpcom_base1.o: In function `nsSystemInfo::Init()':  [ 4083s] /home/abuild/rpmbuild/BUILD/mozilla/xpcom/base/nsSystemInfo.cpp:692: undefined reference to `gtk_read_end_of_the_pipe'  [ 4083s] /usr/lib64/gcc/x86_64-suse-linux/6/../../../../x86_64-suse-linux/bin/ld: ../../xpcom/base/Unified_cpp_xpcom_base1.o: relocation R_X86_64_PC32 against undefined hidden symbol `gtk_read_end_of_the_pipe' can not be used when making a shared object  [ 4083s] /usr/lib64/gcc/x86_64-suse-linux/6/../../../../x86_64-suse-linux/bin/ld: final link failed: Bad value