User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

Compile Firefox on a Wayland-only system without xlib etc.

Actual results:

Doesn't build, multiple errors

Expected results:

Successful compilation

That is how far I got patching out X11 related bits. Now I'm stuck because the in-tree cairo apparently doesn't support GLES. Attempts to re-enable system-cairo (which is built for GLES but without OpenGL support) didn't work because the (FreeType related) API has changed.

Any suggestions/help/input are welcome! Thanks!

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

GTK2 isn't compatible with Wayland and requires X11. No functional
change.

GTK3 can work on Wayland without X11. Required in preparation for a
Wayland-only build.

Depends on D88797

Depends on D88798

The build breaks without MOZ_X11 because gboolean and guint are
undefined.

Depends on D88799

Required in preparation for a Wayland-only build.

Depends on D88800

The following headers are only needed on systems runnig X11:

#include <gdk/gdkx.h>
#include <gtk/gtkx.h>
#include <X11/Xlib.h>
#include <X11/Xutil.h>

Depends on D88801

Depends on D88802

Backed out for causing build bustages.

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&resultStatus=testfailed%2Cbusted%2Cexception&revision=b01a3dceb3eb8a60930b7948fd57d180820c7a91&selectedTaskRun=LXn9J-hbRgmdY_s_hEp3YQ.0

Failure log: https://treeherder.mozilla.org/logviewer?job_id=320804862&repo=autoland

[task 2020-11-05T09:56:10.175Z] 09:56:10  WARNING -  [style 0.0.1] Warning: can't set `match_block_trailing_comma = true`, unstable features are only available in nightly channel.
[task 2020-11-05T09:56:10.175Z] 09:56:10     INFO -     Compiling fxa-client v0.1.0 (https://github.com/mozilla/application-services?rev=1c4dd52e61324eb124ba41cfbb56dcbc6b930d9f#1c4dd52e)
[task 2020-11-05T09:56:10.178Z] 09:56:10     INFO -       Running `CARGO=/builds/worker/fetches/rustc/bin/cargo CARGO_MANIFEST_DIR=/builds/worker/checkouts/gecko/third_party/rust/fxa-client CARGO_PKG_AUTHORS='Edouard Oger <eoger@fastmail.com>' CARGO_PKG_DESCRIPTION= CARGO_PKG_HOMEPAGE= CARGO_PKG_NAME=fxa-client CARGO_PKG_REPOSITORY= CARGO_PKG_VERSION=0.1.0 CARGO_PKG_VERSION_MAJOR=0 CARGO_PKG_VERSION_MINOR=1 CARGO_PKG_VERSION_PATCH=0 CARGO_PKG_VERSION_PRE= LD_LIBRARY_PATH='/builds/worker/workspace/obj-build/debug/deps:/builds/worker/fetches/rustc/lib:/builds/worker/workspace/obj-build/dist/bin:/builds/worker/fetches/gcc/lib64:/builds/worker/fetches/gcc/lib32:/builds/worker/fetches/gcc/lib' /builds/worker/fetches/sccache/sccache /builds/worker/fetches/rustc/bin/rustc --crate-name fxa_client --edition=2018 /builds/worker/checkouts/gecko/third_party/rust/fxa-client/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C opt-level=1 -C panic=abort -C debuginfo=2 -C debug-assertions=on --cfg 'feature="default"' --cfg 'feature="gecko"' -C metadata=0e20d7fb45ede2dc -C extra-filename=-0e20d7fb45ede2dc --out-dir /builds/worker/workspace/obj-build/x86_64-unknown-linux-gnu/debug/deps --target x86_64-unknown-linux-gnu -C linker=/builds/worker/checkouts/gecko/build/cargo-linker -L dependency=/builds/worker/workspace/obj-build/x86_64-unknown-linux-gnu/debug/deps -L dependency=/builds/worker/workspace/obj-build/debug/deps --extern anyhow=/builds/worker/workspace/obj-build/x86_64-unknown-linux-gnu/debug/deps/libanyhow-0fe20c3c4d7018fc.rmeta --extern base64=/builds/worker/workspace/obj-build/x86_64-unknown-linux-gnu/debug/deps/libbase64-dc3fd5d11f30f837.rmeta --extern error_support=/builds/worker/workspace/obj-build/x86_64-unknown-linux-gnu/debug/deps/liberror_support-8ad2ac638475579e.rmeta --extern ffi_support=/builds/worker/workspace/obj-build/x86_64-unknown-linux-gnu/debug/deps/libffi_support-d1f4b3862ed02aee.rmeta --extern hex=/builds/worker/workspace/obj-build/x86_64-unknown-linux-gnu/debug/deps/libhex-72a2c610e0cde68e.rmeta --extern jwcrypto=/builds/worker/workspace/obj-build/x86_64-unknown-linux-gnu/debug/deps/libjwcrypto-ed3dab9788dab2e1.rmeta --extern lazy_static=/builds/worker/workspace/obj-build/x86_64-unknown-linux-gnu/debug/deps/liblazy_static-bb4de943aa03b5c6.rmeta --extern log=/builds/worker/workspace/obj-build/x86_64-unknown-linux-gnu/debug/deps/liblog-7fee9b05e7ad7e60.rmeta --extern prost=/builds/worker/workspace/obj-build/x86_64-unknown-linux-gnu/debug/deps/libprost-157d653401e18e05.rmeta --extern prost_derive=/builds/worker/workspace/obj-build/debug/deps/libprost_derive-2f453c0b519b5e6a.so --extern rand_rccrypto=/builds/worker/workspace/obj-build/x86_64-unknown-linux-gnu/debug/deps/librand_rccrypto-0027c7aadd7c858f.rmeta --extern rc_crypto=/builds/worker/workspace/obj-build/x86_64-unknown-linux-gnu/debug/deps/librc_crypto-853bdcb174b0a4ac.rmeta --extern serde=/builds/worker/workspace/obj-build/x86_64-unknown-linux-gnu/debug/deps/libserde-3fe387c1918e0335.rmeta --extern serde_derive=/builds/worker/workspace/obj-build/debug/deps/libserde_derive-846fd224bf9d2aed.so --extern serde_json=/builds/worker/workspace/obj-build/x86_64-unknown-linux-gnu/debug/deps/libserde_json-c5382b9c16f9f9f0.rmeta --extern sync_guid=/builds/worker/workspace/obj-build/x86_64-unknown-linux-gnu/debug/deps/libsync_guid-9e72a134f55ccd8d.rmeta --extern sync15=/builds/worker/workspace/obj-build/x86_64-unknown-linux-gnu/debug/deps/libsync15-d5f468e5296edfd9.rmeta --extern thiserror=/builds/worker/workspace/obj-build/x86_64-unknown-linux-gnu/debug/deps/libthiserror-60164b30be09ac30.rmeta --extern url=/builds/worker/workspace/obj-build/x86_64-unknown-linux-gnu/debug/deps/liburl-764a3ac1e7167f0a.rmeta --extern viaduct=/builds/worker/workspace/obj-build/x86_64-unknown-linux-gnu/debug/deps/libviaduct-a9c3c8641002822e.rmeta --cap-lints warn -C opt-level=2 -C debuginfo=2 -C force-frame-pointers=yes -Dwarnings -C codegen-units=1`
[task 2020-11-05T09:56:10.178Z] 09:56:10    ERROR -  error[E0658]: use of unstable library feature 'str_strip': newly added
[task 2020-11-05T09:56:10.178Z] 09:56:10     INFO -    --> /builds/worker/checkouts/gecko/third_party/rust/fxa-client/src/config.rs:82:41
[task 2020-11-05T09:56:10.178Z] 09:56:10     INFO -     |
[task 2020-11-05T09:56:10.178Z] 09:56:10     INFO -  82 |         match token_server_url_override.strip_suffix("/1.0/sync/1.5") {
[task 2020-11-05T09:56:10.179Z] 09:56:10     INFO -     |                                         ^^^^^^^^^^^^
[task 2020-11-05T09:56:10.179Z] 09:56:10     INFO -     |
[task 2020-11-05T09:56:10.179Z] 09:56:10     INFO -     = note: see issue #67302 <https://github.com/rust-lang/rust/issues/67302> for more information
[task 2020-11-05T09:56:10.179Z] 09:56:10    ERROR -  error: aborting due to previous error
[task 2020-11-05T09:56:10.179Z] 09:56:10     INFO -  For more information about this error, try `rustc --explain E0658`.
[task 2020-11-05T09:56:10.179Z] 09:56:10     INFO -  error: could not compile `fxa-client`.
[task 2020-11-05T09:56:10.179Z] 09:56:10     INFO -  Caused by:
[task 2020-11-05T09:56:10.183Z] 09:56:10     INFO -    process didn't exit successfully: `CARGO=/builds/worker/fetches/rustc/bin/cargo CARGO_MANIFEST_DIR=/builds/worker/checkouts/gecko/third_party/rust/fxa-client CARGO_PKG_AUTHORS='Edouard Oger <eoger@fastmail.com>' CARGO_PKG_DESCRIPTION= CARGO_PKG_HOMEPAGE= CARGO_PKG_NAME=fxa-client CARGO_PKG_REPOSITORY= CARGO_PKG_VERSION=0.1.0 CARGO_PKG_VERSION_MAJOR=0 CARGO_PKG_VERSION_MINOR=1 CARGO_PKG_VERSION_PATCH=0 CARGO_PKG_VERSION_PRE= LD_LIBRARY_PATH='/builds/worker/workspace/obj-build/debug/deps:/builds/worker/fetches/rustc/lib:/builds/worker/workspace/obj-build/dist/bin:/builds/worker/fetches/gcc/lib64:/builds/worker/fetches/gcc/lib32:/builds/worker/fetches/gcc/lib' /builds/worker/fetches/sccache/sccache /builds/worker/fetches/rustc/bin/rustc --crate-name fxa_client --edition=2018 /builds/worker/checkouts/gecko/third_party/rust/fxa-client/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C opt-level=1 -C panic=abort -C debuginfo=2 -C debug-assertions=on --cfg 'feature="default"' --cfg 'feature="gecko"' -C metadata=0e20d7fb45ede2dc -C extra-filename=-0e20d7fb45ede2dc --out-dir /builds/worker/workspace/obj-build/x86_64-unknown-linux-gnu/debug/deps --target x86_64-unknown-linux-gnu -C linker=/builds/worker/checkouts/gecko/build/cargo-linker -L dependency=/builds/worker/workspace/obj-build/x86_64-unknown-linux-gnu/debug/deps -L dependency=/builds/worker/workspace/obj-build/debug/deps --extern anyhow=/builds/worker/workspace/obj-build/x86_64-unknown-linux-gnu/debug/deps/libanyhow-0fe20c3c4d7018fc.rmeta --extern base64=/builds/worker/workspace/obj-build/x86_64-unknown-linux-gnu/debug/deps/libbase64-dc3fd5d11f30f837.rmeta --extern error_support=/builds/worker/workspace/obj-build/x86_64-unknown-linux-gnu/debug/deps/liberror_support-8ad2ac638475579e.rmeta --extern ffi_support=/builds/worker/workspace/obj-build/x86_64-unknown-linux-gnu/debug/deps/libffi_support-d1f4b3862ed02aee.rmeta --extern hex=/builds/worker/workspace/obj-build/x86_64-unknown-linux-gnu/debug/deps/libhex-72a2c610e0cde68e.rmeta --extern jwcrypto=/builds/worker/workspace/obj-build/x86_64-unknown-linux-gnu/debug/deps/libjwcrypto-ed3dab9788dab2e1.rmeta --extern lazy_static=/builds/worker/workspace/obj-build/x86_64-unknown-linux-gnu/debug/deps/liblazy_static-bb4de943aa03b5c6.rmeta --extern log=/builds/worker/workspace/obj-build/x86_64-unknown-linux-gnu/debug/deps/liblog-7fee9b05e7ad7e60.rmeta --extern prost=/builds/worker/workspace/obj-build/x86_64-unknown-linux-gnu/debug/deps/libprost-157d653401e18e05.rmeta --extern prost_derive=/builds/worker/workspace/obj-build/debug/deps/libprost_derive-2f453c0b519b5e6a.so --extern rand_rccrypto=/builds/worker/workspace/obj-build/x86_64-unknown-linux-gnu/debug/deps/librand_rccrypto-0027c7aadd7c858f.rmeta --extern rc_crypto=/builds/worker/workspace/obj-build/x86_64-unknown-linux-gnu/debug/deps/librc_crypto-853bdcb174b0a4ac.rmeta --extern serde=/builds/worker/workspace/obj-build/x86_64-unknown-linux-gnu/debug/deps/libserde-3fe387c1918e0335.rmeta --extern serde_derive=/builds/worker/workspace/obj-build/debug/deps/libserde_derive-846fd224bf9d2aed.so --extern serde_json=/builds/worker/workspace/obj-build/x86_64-unknown-linux-gnu/debug/deps/libserde_json-c5382b9c16f9f9f0.rmeta --extern sync_guid=/builds/worker/workspace/obj-build/x86_64-unknown-linux-gnu/debug/deps/libsync_guid-9e72a134f55ccd8d.rmeta --extern sync15=/builds/worker/workspace/obj-build/x86_64-unknown-linux-gnu/debug/deps/libsync15-d5f468e5296edfd9.rmeta --extern thiserror=/builds/worker/workspace/obj-build/x86_64-unknown-linux-gnu/debug/deps/libthiserror-60164b30be09ac30.rmeta --extern url=/builds/worker/workspace/obj-build/x86_64-unknown-linux-gnu/debug/deps/liburl-764a3ac1e7167f0a.rmeta --extern viaduct=/builds/worker/workspace/obj-build/x86_64-unknown-linux-gnu/debug/deps/libviaduct-a9c3c8641002822e.rmeta --cap-lints warn -C opt-level=2 -C debuginfo=2 -C force-frame-pointers=yes -Dwarnings -C codegen-units=1` (exit code: 1)
[task 2020-11-05T09:56:10.183Z] 09:56:10     INFO -  warning: build failed, waiting for other jobs to finish...

Backout link: https://hg.mozilla.org/integration/autoland/rev/b4ef67c8a32e519c69a235f1e3e4baea5d730e10

Considering bug 1675349, this becomes wontfix.

Actually, there might be some parts that still apply after bug 1675349, but this should wait for that bug.

Relanded the patch, the failures were actually caused by bug 1675190 and were fixed by the following backout: https://hg.mozilla.org/integration/autoland/rev/4cb5c0af79d689a8b399fc3b769040ad3da4e245

https://hg.mozilla.org/mozilla-central/rev/8450204dac8a
https://hg.mozilla.org/mozilla-central/rev/ed6cf2a64100
https://hg.mozilla.org/mozilla-central/rev/108fafa72831
https://hg.mozilla.org/mozilla-central/rev/90fde6a48cb4
https://hg.mozilla.org/mozilla-central/rev/650d068602d2

There are some patches left.

Depends on #1661450

Does this also address Bug#1614266

I'm trying to build firefox without MOZ_X11. @philipp.ammann I'm not sure what GLES issue you get with cairo, cairo seems to build correctly with this little patch enabling postscript surfaces when MOZ_X11 is undefined.

However, there are a lot of patches needed:

• MOZ_WIDGET_GTK often (but not always) implies MOZ_X11, so many ifdefs have to be adjusted
• Many X11 dependencies are not guarded by MOZ_X11
• !GDK_IS_X11_DISPLAY which requires x11 is called in wayland code, it needs to be replaced by GDK_IS_WAYLAND_DISPLAY (bug #1614266)

I'm trying to patch it, and send the patches here if working. For now, my biggest blocker is webrtc, so I'll first try to build firefox with --disable-webrtc.

This introduces only MOZ_X11 ifdefs, there should be no functional changes.

Opt out X or GTK2 specific components in the build system, there should be no functional change

Re-enable all wayland required components that get disabled when disabling MOZ_X11, there should be no functional changes

There are mainly two things:

• add some || defined(MOZ_WAYLAND) when code is shared with X11
• replace GDK_IS_X11_DISPLAY with GDK_IS_WAYLAND_DISPLAY when guarded by MOZ_WAYLAND

There should no functional change for X11 builds.

ApplyTransparencyBitmap contains plain cairo code when MOZ_X11 is undefined, but this code is not compiling (?legacy code?). This function is only called once in ClearTransparencyBitmap as last resort when other mechanism did not succeed. I have no idea how to trigger it, or if it even gets called on wayland.

Use pkgconfig to detect X availability, disable MOZ_X11 when wayland is enabled and X dependencies are missing as suggested by D88798

these patches are made against https://github.com/mozilla/gecko-dev/ (commit 1e96a1abb42dd8d4f8a1d0e163c4290197c5dee9).

I tested them on 84.0.1 (slightly modified) and 86.0a1. Builds with X11 still worked, there seem to be no functional change. Wayland-only builds without X work for the procided mozconfig, but as mentioned previously with webrtc disabled.

Here is the used mozconfig. (It was performed on a Gentoo system without the common Gentoo patches for firefox)

Attempting to use Michel's patches and setting MOZ_ENABLE_WAYLAND=1 results in gtk complaining about being unable to find a display (other GTK apps have no complaints). Similar issues with patches slightly modified for 84.0.1.

Also had to add #include "nsRemoteClient.h" to toolkit/components/remote/nsRemoteServer.cpp, presumably because I'm building without dbus so everything that would be including this header isn't being included - not sure how to cleanly fix this without a bunch of ifndef's?

For thoroughness, I'm running a strictly wayland-only system (just libxkbcommon and xkeyboard-config). My configure options for firefox:

export LDFLAGS="$LDFLAGS -Wl,-rpath=/usr/lib/firefox"
export RUSTFLAGS="$RUSTFLAGS -Cdebuginfo=0"
export MOZ_DEBUG_FLAGS=-g0
export MOZ_NOSPAM=1
export CXXSTDLIB=c++
export SHELL=/bin/sh
export BUILD_OFFICIAL=1
export MOZILLA_OFFICIAL=1
export USE_SHORT_LIBNAME=1
export MACH_USE_SYSTEM_PYTHON=1

../mach configure \
--prefix=/usr \
--libdir=/usr/lib \
--enable-optimize="$CFLAGS -w" \
--enable-official-branding \
--enable-install-strip \
--enable-strip \
--enable-rust-simd \
--enable-application=browser \
--enable-release \
--enable-alsa \
--without-system-nspr \
--without-system-nss \
--without-system-libvpx \
--with-system-jpeg \
--with-system-zlib \
--with-system-png \
--with-system-pixman \
--with-system-ffi \
--disable-profiling \
--disable-accessibility \
--disable-tests \
--disable-system-extension-dirs \
--disable-parental-controls \
--disable-debug-symbols \
--disable-callgrind \
--disable-vtune \
--disable-elf-hack \
--disable-gold \
--disable-jemalloc \
--disable-pulseaudio \
--disable-crashreporter \
--disable-updater \
--disable-dbus \
--disable-eme \
--disable-necko-wifi \
--disable-webrtc \
--enable-linker=lld \
--enable-default-toolkit=cairo-gtk3-wayland

(In reply to Dilyn Corner from comment #39)

Attempting to use Michel's patches and setting MOZ_ENABLE_WAYLAND=1 results in gtk complaining about being unable to find a display (other GTK apps have no complaints). Similar issues with patches slightly modified for 84.0.1.

Also had to add #include "nsRemoteClient.h" to toolkit/components/remote/nsRemoteServer.cpp, presumably because I'm building without dbus so everything that would be including this header isn't being included - not sure how to cleanly fix this without a bunch of ifndef's?

For thoroughness, I'm running a strictly wayland-only system (just libxkbcommon and xkeyboard-config). My configure options for firefox:

export LDFLAGS="$LDFLAGS -Wl,-rpath=/usr/lib/firefox"
export RUSTFLAGS="$RUSTFLAGS -Cdebuginfo=0"
export MOZ_DEBUG_FLAGS=-g0
export MOZ_NOSPAM=1
export CXXSTDLIB=c++
export SHELL=/bin/sh
export BUILD_OFFICIAL=1
export MOZILLA_OFFICIAL=1
export USE_SHORT_LIBNAME=1
export MACH_USE_SYSTEM_PYTHON=1

../mach configure \
--prefix=/usr \
--libdir=/usr/lib \
--enable-optimize="$CFLAGS -w" \
--enable-official-branding \
--enable-install-strip \
--enable-strip \
--enable-rust-simd \
--enable-application=browser \
--enable-release \
--enable-alsa \
--without-system-nspr \
--without-system-nss \
--without-system-libvpx \
--with-system-jpeg \
--with-system-zlib \
--with-system-png \
--with-system-pixman \
--with-system-ffi \
--disable-profiling \
--disable-accessibility \
--disable-tests \
--disable-system-extension-dirs \
--disable-parental-controls \
--disable-debug-symbols \
--disable-callgrind \
--disable-vtune \
--disable-elf-hack \
--disable-gold \
--disable-jemalloc \
--disable-pulseaudio \
--disable-crashreporter \
--disable-updater \
--disable-dbus \
--disable-eme \
--disable-necko-wifi \
--disable-webrtc \
--enable-linker=lld \
--enable-default-toolkit=cairo-gtk3-wayland

I start firefox with GDK_BACKEND=wayland, nothing else. For nsRemote, yes only dbus seems supported for wayland.

GDK_BACKEND=wayland results in an identical message.

@micel: Can verify that these patches work. They also circumvent the requirement of needing gtk2 to build as well. Also using gentoo and have shared an ebuild against this here... https://github.com/ambasta/ambasta/blob/master/www-client/firefox/firefox-85.0_beta7.ebuild

However, with webrtc, it runs into linking errors

Bug 1640053 should also have helped here a bit.

I played a bit with webrtc under wayland, with this patch it compiles and seems to work (didn't fully test it though)

This patch allows libwebrtc to build without use_x11 on a wayland only system:

• Use desktop_device_info_null when no desktop_device_info_x11
• Add missing function in desktop_device_info_null.cc
• Guard gtk/gtkx import in desktop_capturer.cc

Upstream patches? desktop_device_info is mozilla specific and the gtkx import has already been removed (it is actually not used)

This patch does not include (I'm not sure how to do it correctly):

• Removal of define USE_X11 and X libraries in all moz.build under third_party/libwebrtc and under dom/media/webrtc/third_party_build/gn-configs JSON files.
• Ensure use_x11 does not get automatically enabled in third_party/libwebrtc/webrtc/build/config/ui.gni
• Ensure USE_X11 does not get automatically defined in third_party/libwebrtc/webrtc/build/build_config.h

Hi,

I'm testing this patchset with 85.0.1 (the 8 patches from 1 month ago, and the webrtc-without-x11 patch).

After getting the patches to apply cleanly, not matter what I try, MOZ_X11 is always '1' after running the configure phase. Here are my configure options:

export LDFLAGS="$LDFLAGS -Wl,-rpath=/usr/lib/firefox"
export RUSTFLAGS="$RUSTFLAGS -Cdebuginfo=0"
export MACH_USE_SYSTEM_PYTHON=1
export MOZ_DEBUG_FLAGS=-g0
export MOZ_NOSPAM=1

./mach configure \
    --prefix=/usr \
    --libdir=/usr/lib \
    --enable-official-branding \
    --enable-optimize="$CFLAGS -w" \
    --enable-install-strip \
    --enable-strip \
    --enable-rust-simd \
    --enable-application=browser \
    --enable-release \
    --enable-alsa \
    --without-system-nspr \
    --without-system-nss \
    --with-system-jpeg \
    --with-system-zlib \
    --with-system-png \
    --without-system-libvpx \
    --with-system-pixman \
    --with-system-ffi \
    --disable-profiling \
    --disable-accessibility \
    --disable-tests \
    --disable-system-extension-dirs \
    --disable-parental-controls \
    --disable-debug-symbols \
    --disable-callgrind \
    --disable-vtune \
    --disable-elf-hack \
    --disable-gold \
    --disable-jemalloc \
    --disable-pulseaudio \
    --disable-crashreporter \
    --disable-updater \
    --disable-dbus \
    --disable-eme \
    --disable-necko-wifi \
    --enable-default-toolkit=cairo-gtk3-wayland

Is there any way of forcing MOZ_X11=0?

Thanks.

(In reply to John Rowley from comment #45)

Hi,

I'm testing this patchset with 85.0.1 (the 8 patches from 1 month ago, and the webrtc-without-x11 patch).

After getting the patches to apply cleanly, not matter what I try, MOZ_X11 is always '1' after running the configure phase. Here are my configure options:

export LDFLAGS="$LDFLAGS -Wl,-rpath=/usr/lib/firefox"
export RUSTFLAGS="$RUSTFLAGS -Cdebuginfo=0"
export MACH_USE_SYSTEM_PYTHON=1
export MOZ_DEBUG_FLAGS=-g0
export MOZ_NOSPAM=1

./mach configure \
    --prefix=/usr \
    --libdir=/usr/lib \
    --enable-official-branding \
    --enable-optimize="$CFLAGS -w" \
    --enable-install-strip \
    --enable-strip \
    --enable-rust-simd \
    --enable-application=browser \
    --enable-release \
    --enable-alsa \
    --without-system-nspr \
    --without-system-nss \
    --with-system-jpeg \
    --with-system-zlib \
    --with-system-png \
    --without-system-libvpx \
    --with-system-pixman \
    --with-system-ffi \
    --disable-profiling \
    --disable-accessibility \
    --disable-tests \
    --disable-system-extension-dirs \
    --disable-parental-controls \
    --disable-debug-symbols \
    --disable-callgrind \
    --disable-vtune \
    --disable-elf-hack \
    --disable-gold \
    --disable-jemalloc \
    --disable-pulseaudio \
    --disable-crashreporter \
    --disable-updater \
    --disable-dbus \
    --disable-eme \
    --disable-necko-wifi \
    --enable-default-toolkit=cairo-gtk3-wayland

Is there any way of forcing MOZ_X11=0?

Thanks.

As I said above, you'll need to remove all definitions of hardcoded MOZ_X11=1 and X11 libraries. There seems to be some kind of webrtc integration script that generates all the build config. However, I did'nt clearly find how to se it. So my solution is to manually edit all the build file and remove everything. the real solution is to make it dependant on the main MOZ_X11 build flag. This is why I didn't want to publish my dirty patch. But here's it is...

Note: MOZ_X11 needs to be undefined, MOZ_X11=0 would still be defined and would not work.

This is for information for those who want to try my patch, but it dirty and definitely not the solution. Note that it includes my previous posted patch 9197561: webrtc-without-x11.patch

For the record: webrtc currently also opens X11 connection on the Wayland backend - when running a session with Xwayland on demand this means Xwayland gets started as soon as webrtc is loaded. Sounds like this has to wait for bug 1654112 to have landed, maybe the situation is already better then.

Hello,

Here is a no-x11 patch I created for Firefox 90. Just dropping it here
so anyone interested can find it.

https://github.com/kisslinux/repo/blob/8c28694cbd01ca30490f9977e2e94d8b48eaec39/extra/firefox/patches/no-x11.patch

NOTE: The webrtc code is untouched so --disable-webrtc must be used.

Now that webrtc 2H20 has landed, does it still require a X11 connection on the wayland backend?

The bug assignee didn't login in Bugzilla in the last 7 months.
:stransky, could you have a look please?
For more information, please visit auto_nag documentation.

@Amit Prakash Ambasta No, new webrtc integration still has hardcoded X11.

@stransky @marco @calixte I'm keeping the patches up to date with firefox releases. I would be happy to submit them. But I already did it once with no feedback. So I'll only do it again if there is interest to accept the patches!

(In reply to michel from comment #52)

@Amit Prakash Ambasta No, new webrtc integration still has hardcoded X11.

@stransky @marco @calixte I'm keeping the patches up to date with firefox releases. I would be happy to submit them. But I already did it once with no feedback. So I'll only do it again if there is interest to accept the patches!

Please submit the patches via phabricator and ask me for review.
Thanks.

Add MOZ_X11 ifdefs on X11 specific code, mainly alongside GdkIsX11Display.

Ensure shared code with MOZ_X11 and MOZ_WAYLAND remains when MOZ_X11 is
undefined

Depends on D139526

Change !GDK_IS_X11_DISPLAY to GDK_IS_WAYLAND_DISPLAY and additionally guard it
with MOZ_WAYLAND to ensure it gets correct in all cases:

• When only MOZ_X11 is defined (thus MOZ_WAYLAND undefined)
• When only MOZ_WAYLAND is defined
• When both MOZ_X11 and MOZ_WAYLAND are defined

Depends on D139528

Add missing includes from opting out X11 specific includes.

Remove unused gdk/gdkx.h includes.

Depends on D139529

Force usage of EGL when building for wayland only.

Enable build component that get disabled by undefined MOZ_X11 but are required
for MOZ_WAYLAND.

Depends on D139530

Depends on D139531

Opt out of X11 code makes mozgtk.c empty. But following the comment in the
file, it requires at least a symbol to force libxul to depend on it.

Therefore I added a common gtk function. However, I don't know if adding that
chosen function can have unwanted side-effects.

Depends on D139532

Allow builds without MOZ_X11 when toolkit is cairo-gtk3-wayland and X11
dependencies are missing.

Depends on D139533

These phabricator published patches do not handle webrtc. For webrtc I'm not sure how to proceed, can you please provide some information how webrtc's GN build integrates with moz build?

• gn-configs JSON files (e.g. dom/media/webrtc/third_party_build/gn-configs/x64_False_x64_linux.json): There are several instances of USE_X11=1 and lists of X11 libs and X11 specific files. I don't know how to proceed to make them honor MOZ_X11
• BUILD.gn files and .gni config files: Same as above, how to make them honor MOZ_X11?
• moz.build files (e.g. third_party/libwebrtc/api/adaptation/resource_adaptation_api_gn/moz.build): I can guard all DEFINES["USE_X11"] = "1" (and X11 specific OS_LIBS and UNIFIED_SOURCES) with if CONFIG["MOZ_X11"]:.

The attached patch is a dirty patch of what needs to be opted out when MOZ_X11 is undefined. There are a lot of files, the patch was generated with few sed scripts.

(In reply to michel from comment #62)

Created attachment 9265262 [details] [diff] [review]
99-disable-x11-in-webrtc-dirty-patch.patch

These phabricator published patches do not handle webrtc. For webrtc I'm not sure how to proceed, can you please provide some information how webrtc's GN build integrates with moz build?

That's pretty tricky - I did that here https://bugzilla.mozilla.org/show_bug.cgi?id=1739142#c8
You need to build Firefox tree for all arches and generated that setup for it.

Let me know if you have any troubles with that. I'd file a new bug against WebRTC as it's extra component with its own config.

Depends on D139534

Depends on D139660

Depends on D139661

Depends on D139663

Not sure if I've gotten this right, but I think I have the patches for webrtc w/o X11 as per the documentation here

Have split the patch into two parts, one where gni changes were made, and another which contains auto-generated mozbuild files after running generate-gn-build-files.sh

Patch 2/2 : Autogenerated gni files from generate-gn-build-files.sh

1/2 of no-x11 changes for webrtc. Accidently, linked the same patch twice

(In reply to Amit Prakash Ambasta from comment #68)

Created attachment 9267505 [details] [diff] [review]
0030-Auto-generated-mozbuild-gn-configs-based-on-gni-chan.patch

Not sure if I've gotten this right, but I think I have the patches for webrtc w/o X11 as per the documentation here

Have split the patch into two parts, one where gni changes were made, and another which contains auto-generated mozbuild files after running generate-gn-build-files.sh

Yes, I also started trying to disable x11 flags in third_party/libwebrtc/, similar to your patch, the changes required are simple:

• disable use_x11 in third_party/libwebrtc/build/config/ui.gni (changes to use_xvfb_in_this_config seems not required, I think it is only for testing of webrtc and seems not used in Firefox)
• disable rtc_use_x11 in third_party/libwebrtc/webrtc.gni
• From what you could experience: You don't need to manually patch desktop_capture_generic_gn/moz.build, it gets automatically modified by generate-gn-build-files.sh.

It builds fine. However, setting the x11 variables to false is not a generic change, there are 2 things I could not figure out:

• How to use a flag from the mozilla build system (MOZ_X11) in the libwebrtc gni files (if MOZ_X11: use_x11 and if MOZ_X11: rtc_use_x11)?
• Running generate-gn-build-files.sh correctly updates the mozilla build system, however the files are different when using X11 compared to when not. Is there a way to generate if CONFIG['MOZ_X11'] in the resulting moz.build files? Or would that mean add a MOZ_X11 mozbuild_args to the JSON files in dom/media/webrtc/third_party_build/gn-configs (like the MOZ_DEBUG flag) and generate-gn-build-files.sh would have to duplicate all the JSON files to have two versions: respectively with and without X11?

Michael, can you please help with the issue above? I have zero experience with gn build system.
Thanks.

I just returned from PTO, so I'll try to answer this as quickly as I can (probably Monday). Leaving NI on as a reminder.

michel, I think you will need to alter the python script that generates the mozconfig files. I would start by looking here: https://searchfox.org/mozilla-central/rev/1c54648c082efdeb08cf6a5e3a8187e83f7549b9/python/mozbuild/mozbuild/gn_processor.py#156 . I am not an expert on that script, but I think that list encompasses all of the conditionals that are found in the generated mozconfigs.

Thanks for the pointers, here is what I came up to (WIP):

• add the MOZ_X11 config flag in build/gn.mozbuild and set the gn_vars accordingly.
• create the new gn-config/mozconfig files dom/media/webrtc/third_party_build/gn-configs/**.mozconfig with --enable-default-toolkit=cairo-gtk3-wayland for the non X11 version. (For the moment, this patch only contains x64 versions)
• Add the MOZ_X11 config flag in python/mozbuild/mozbuild/gn_processor.py

Then run dom/media/webrtc/third_party_build/gn-configs/generate-gn-build-files.sh (also patched with the additional gn-configs _True/_False). It kind of works but I hit several issues:

• @stransky: The bootstrap sysroot coming with --enable-bootstrap does not includes pipewire. Thus running generate-gn-build-files.sh removes the pipewire bits (LOCAL_INCLUDES). How did you proceed to add the pipewire includes, when I'm running the generate script they always get removed.
• @stansky: The bootstrap sysroot obviously comes with X11 and toolkit/moz.configure autodetects X11 with pkgconfig, so no way to disable X11 with a config option (when= should be used instead of allow_missing= to "force" disable X11). Should I add a new toolkit string (e.g. cairo-gtk3-wayland-only) to allow "force" disabling X11?
• @mjf: This patch adds new gn-configs files (new mozconfig files and running the generate script creates all the json files). This doubles the amount and renames the files (_True/_False versions for MOZ_X11). It is probably not a problem, but what about other OSes (win, mac, openbsd), from my understanding the change in this patch will affect all OSes. Is there a way to restrict the change to Linux? I'm far from fully understanding gn_processor.py, but I'll try to make it conditional for Linux only. But I'll personally be unable to test it on other archs.

(In reply to michel from comment #75)

Created attachment 9270621 [details] [diff] [review]
webrtc-x11-optional.patch

Thanks for the pointers, here is what I came up to (WIP):

• add the MOZ_X11 config flag in build/gn.mozbuild and set the gn_vars accordingly.
• create the new gn-config/mozconfig files dom/media/webrtc/third_party_build/gn-configs/**.mozconfig with --enable-default-toolkit=cairo-gtk3-wayland for the non X11 version. (For the moment, this patch only contains x64 versions)
• Add the MOZ_X11 config flag in python/mozbuild/mozbuild/gn_processor.py

Then run dom/media/webrtc/third_party_build/gn-configs/generate-gn-build-files.sh (also patched with the additional gn-configs _True/_False). It kind of works but I hit several issues:

• @stransky: The bootstrap sysroot coming with --enable-bootstrap does not includes pipewire. Thus running generate-gn-build-files.sh removes the pipewire bits (LOCAL_INCLUDES). How did you proceed to add the pipewire includes, when I'm running the generate script they always get removed.
• @stansky: The bootstrap sysroot obviously comes with X11 and toolkit/moz.configure autodetects X11 with pkgconfig, so no way to disable X11 with a config option (when= should be used instead of allow_missing= to "force" disable X11). Should I add a new toolkit string (e.g. cairo-gtk3-wayland-only) to allow "force" disabling X11?
• @mjf: This patch adds new gn-configs files (new mozconfig files and running the generate script creates all the json files). This doubles the amount and renames the files (_True/_False versions for MOZ_X11). It is probably not a problem, but what about other OSes (win, mac, openbsd), from my understanding the change in this patch will affect all OSes. Is there a way to restrict the change to Linux? I'm far from fully understanding gn_processor.py, but I'll try to make it conditional for Linux only. But I'll personally be unable to test it on other archs.

Ignore my previous comment, it seems my issues mostly come from testing only x64, when doing all archs, it behaves differently. I'll come back when I'm more advanced on the patch.

1. add the MOZ_X11 config flag in build/gn.mozbuild and set the gn_vars
   accordingly.

2. create the new gn-config/mozconfig files and delete previous ones
   dom/media/webrtc/third_party_build/gn-configs/**.mozconfig with
   --enable-default-toolkit=cairo-gtk3-wayland-only for the non X11 version.
   New toolkit nmae is required to force disable X11 detection as
   cairo-gtk3-wayland will auto-detect X11 and make generate-gn-build-files.sh
   fail.

3. Add the MOZ_X11 config flag in python/mozbuild/mozbuild/gn_processor.py

Then run
dom/media/webrtc/third_party_build/gn-configs/generate-gn-build-files.sh

Depends on D139534

dom/media/webrtc/third_party_build/gn-configs/generate-gn-build-files.sh:

• regenerated json and moz.build files
• remove previous json files

Depends on D142904

Backed out for causing build bustages on nsWindow.cpp

Backout link : https://hg.mozilla.org/integration/autoland/rev/2619aa0051942c3c916e068e6be3435dd6994485

Push with failures : https://treeherder.mozilla.org/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception%2Crunnable&revision=2c41d82de0c524cd6b33fcaa7a69c5f4c3d7a1f9&selectedTaskRun=Kgpc0I8fTh2mK7cASeXyhg.0

Link to failure log :
https://treeherder.mozilla.org/logviewer?job_id=374946196&repo=autoland&lineNumber=27463
https://treeherder.mozilla.org/logviewer?job_id=374946225&repo=autoland&lineNumber=34070

Will look at it.

try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=788967f1052c1d8c44db8c4a8e6b5ec524816dc1

https://hg.mozilla.org/mozilla-central/rev/ad1ec41524fd
https://hg.mozilla.org/mozilla-central/rev/ce53ae737f38
https://hg.mozilla.org/mozilla-central/rev/96f37f828516
https://hg.mozilla.org/mozilla-central/rev/e09436c5fd49
https://hg.mozilla.org/mozilla-central/rev/b8a92647608e
https://hg.mozilla.org/mozilla-central/rev/488cf51af6d5
https://hg.mozilla.org/mozilla-central/rev/c2abd7150c7b
https://hg.mozilla.org/mozilla-central/rev/f3166553895e
https://hg.mozilla.org/mozilla-central/rev/0f44ceba842f
https://hg.mozilla.org/mozilla-central/rev/26726cd43095

Is #endif here right?

(In reply to Takanori MATSUURA from comment #85)

Is #endif here right?

Looks ok to me.

So, build without X11 is now possible only with disabled webrtc? No way around it?

(In reply to sorrow from comment #87)

So, build without X11 is now possible only with disabled webrtc? No way around it?

AFAIK webrtc should be fixed by the two latest patches.