Open Bug 635134 (wayland) Opened 11 years ago Updated 2 days ago

[meta] Firefox Wayland port

Categories

(Core :: Graphics, enhancement, P2)

All
Linux
enhancement

Tracking

()

People

(Reporter: Prescience500, Assigned: stransky, NeedInfo)

References

(Depends on 77 open bugs, Blocks 2 open bugs)

Details

(Keywords: feature, leave-open, meta, Whiteboard: [ leave open for tracking ])

Attachments

(2 files, 5 obsolete files)

User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:2.0b12pre) Gecko/20110217 Firefox/4.0b12pre
Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b12pre) Gecko/20110217 Firefox/4.0b12pre

Currently, Linux, as well as other FOSS operating systems, uses X. A replacement for X is currently being developed called Wayland. It would be nice if when Wayland comes out, Firefox would be ready and support Wayland without needing X.

Reproducible: Always




Wayland won't be ready for widespread use for some time. As I understand it (which may be slightly inaccurate), even after it is ready for widespread use, it'll still be used to talk to X in order to speed things up. It'll probably be even longer before Linux desktops are able to ditch X altogether.
Component: General → Widget
Product: Firefox → Core
QA Contact: general → general
Version: unspecified → Trunk
I think what you are proposing is a really good idea that would make FF even more popular between FOSS users.
It seems that Google is working on porting Chrome to Wayland according to Phoronix.
http://www.phoronix.com/scan.php?page=news_item&px=OTc4NA
Mozilla will probably have to port it's products at some point in order to stay competitive on Linux.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Depends on: gtk3
Component: Widget → Graphics
QA Contact: general → thebes
It looks like firefox uses GTK, which should make this easier.  GTK 3.4 supports wayland 0.85.  The page with instructions to build GTK with wayland support also has a "Porting your GTK+ application" section: http://wayland.freedesktop.org/gtk.html

I guess I'll just paste the whole thing here:

The GTK+ port to Wayland has some major functionality gaps. Porting of applications at this stage should simply be to start identifying where applications makes API calls that will not function under Wayland.

    * Ensure that your application uses gtk+-3.0 for its pkg-config request.
    * Your application must not use any API in the gdk_x11_ namespace or any raw Xlib calls.
    * Check the errata below for issues that might affect your application.

API to access the underlying wl_surface, wl_shell_surface and wl_display may be available in later versions of the code but are not available right now.
Other gtk applications are handling this by wrapping xlib calls in "#ifdef GDK_WINDOWING_X11".  I'm curious how much of the gecko gtk3 work could be handled this easily, and how much would require something more involved.
Similar work on gnome-terminal: https://bugzilla.gnome.org/show_bug.cgi?id=673323
Mozilla stuff is not a "gtk application", we only use GTK for a few specific things like getting the theming of our XUL widgets right. Our work to remove direct usages of X Bitmaps and go for GL for everything is way more relevant to potentially running on Wayland than any GTK stuff is.
"#ifdef GDK_WINDOWING_X11" is only a build time check, so it's insufficient.  A run time check is also needed, something like "if (GDK_IS_X11_DISPLAY (display))", documented here:  http://developer.gnome.org/gtk3/3.3/ch24s02.html#id1502079

There are also GDK_IS_X11_SCREEN and GDK_IS_X11_WINDOW.
Robert: Outputting directly via GL sounds lovely, where can I find more info on that effort?  Is there a bug open?
(In reply to Darxus from comment #9)
> Robert: Outputting directly via GL sounds lovely, where can I find more info
> on that effort?  Is there a bug open?

AFAIK there are multiple bug open for that, probably blocking some "enable OpenGL layers by default" bug, just search for OpenGL stuff here in Bugzilla and you should find a few.
(Note that I'm no code, just an interested community member, so I don't know all the details, but I usually have some rough grasp of the overview.)
The ongoing work to stop using X pixmaps directly is an important prerequisite for this. Marking as blockers.
Depends on: 720523, 738937
What about starting from Mobile Firefox? On a tablet it's pretty much like a desktop browser (indeed without some of the bloat of classic desktop Firefox), and porting from Android should be simpler than disentangling the X/GTK mess (I bet Android Firefox doesn't use xpixmaps for example!).
Depends on: 943407
No longer depends on: 943407
Depends on: 1015218
Attached patch Hacks to get firefox on wayland (obsolete) — Splinter Review
I recently looked at this. I tried to get Firefox-gtk3 running on Weston, using hacks wherever needed to avoid X11 calls / paths. After those bunch of hacks (which obviously would need to be done properly), I managed to get Firefox running on Weston, not without issues. More work is needed to turn those hacks into proper checks, to add suitable codepaths for wayland where necessary, and to fix regressions / bugs.

The attached patch is what I used, which as I said is quite hacky. This was tested on top of r186206. Perhaps various / most of those tests aren't necessary if MOZ_X11 is forced to 0 in configure.ac, I didn't try that. In any case, support for both X11 and Wayland in the same binary would be desirable, with runtime detection checks to pick one path or the other.
This is a screenshot of firefox running on weston.

Also see http://emilio.pozuelo.org/?p=75
\o/ cheers for that!
Depends on: 1034064
No longer depends on: 1034064
Attached patch shaped patch (obsolete) — Splinter Review
Karl, can you please check this one? It uses gtkx.h wrapper to provide a GDK_IS_X11_DISPLAY() macro for GTK2 builds.
Attachment #8445763 - Attachment is obsolete: true
Attachment #8566469 - Flags: feedback?(karlt)
Comment on attachment 8566469 [details] [diff] [review]
shaped patch

>+#include <gtk/gtkx.h>
> 
> #include "gfxImageSurface.h"
> #ifdef MOZ_X11
> #include <gdk/gdkx.h>

GDK_IS_X11_DISPLAY should be provided by <gdk/gdkx.h>, so <gtk/gtkx.h> should
be unnecessary, here at least.

>+++ b/widget/gtk/compat/gtk/gtkx.h
>@@ -0,0 +1,14 @@
>+/* This Source Code Form is subject to the terms of the Mozilla Public
>+ * License, v. 2.0. If a copy of the MPL was not distributed with this
>+ * file, You can obtain one at http://mozilla.org/MPL/2.0/. */
>+
>+#ifndef GTKX_WRAPPER_H
>+#define GTKX_WRAPPER_H
>+
>+#if (MOZ_WIDGET_GTK == 3)
>+#include_next <gtk/gtkx.h>
>+#endif
>+
>+#define GDK_IS_X11_DISPLAY(a)   (true)

widget/gtk/compat/gdk/gdkx.h would be the place to define GDK_IS_X11_DISPLAY.

It should only be defined if not already defined,
or only #if (GTK_MAJOR_VERSION == 2).

>+        bool useXlibSurface = (UseXRender() && !UseImageOffscreenSurfaces());
>+        if (useXlibSurface) {
>+            useXlibSurface = GDK_IS_X11_DISPLAY(gdk_display_get_default());
>+        }

Assume that UseXRender() returning true means the default display is an X11
display.

>+  mGdkDisplay = gdk_display_open(display_name);
>+  if (!mGdkDisplay) {
>+    PR_fprintf(PR_STDERR, "Error: cannot open display: %s\n", display_name);
>+    return 1;
>+  }
>+  gdk_display_manager_set_default_display (gdk_display_manager_get(),
>+                                           mGdkDisplay);    
> #endif /* MOZ_WIDGET_GTK */
> 
> #ifdef MOZ_ENABLE_XREMOTE
>   // handle --remote now that xpcom is fired up
>   bool newInstance;
>   {
>     char *e = PR_GetEnv("MOZ_NO_REMOTE");
>     mDisableRemote = (e && *e);
>+#if defined(MOZ_WIDGET_GTK)
>+    if (!GDK_IS_X11_DISPLAY(mGdkDisplay))
>+      mDisableRemote = true;

XInitThreads() needs to be called before Xlib is used.

I wonder whether it would be tidier to set mDisableRemote in the
MOZ_WIDGET_GTK block above and then use
mDisableRemote = mDisableRemove && e && *e;

>   gdk_window_add_filter(mRootWindow, root_window_event_filter, this);
> #ifdef MOZ_X11
>-  mNetWorkareaAtom =
>-    XInternAtom(GDK_WINDOW_XDISPLAY(mRootWindow), "_NET_WORKAREA", False);
>+  if (GDK_IS_X11_DISPLAY(gdk_display_get_default()))
>+      mNetWorkareaAtom =
>+        XInternAtom(GDK_WINDOW_XDISPLAY(mRootWindow), "_NET_WORKAREA", False);
> #endif

I don't know whether Wayland uses properties like _NET_WORKAREA or whether it
has its own mechanisms.  If it uses this property then GDK has
gdk_atom_intern_static_string() for any backend.
If Wayland uses another mechanism, then initialize mNetWorkareaAtom to
something so that it won't match in root_window_event_filter.

>     if (synthEvent) {
> #ifdef MOZ_X11
>-        event.refPoint.x = nscoord(xevent.xmotion.x);
>-        event.refPoint.y = nscoord(xevent.xmotion.y);
>-
>-        modifierState = xevent.xmotion.state;
>-
>-        event.time = xevent.xmotion.time;
>-#else
>-        event.refPoint.x = nscoord(aEvent->x);
>-        event.refPoint.y = nscoord(aEvent->y);
>-
>-        modifierState = aEvent->state;
>-
>-        event.time = aEvent->time;
>+        if (isX11Display) {
>+            event.refPoint.x = nscoord(xevent.xmotion.x);
>+            event.refPoint.y = nscoord(xevent.xmotion.y);
>+
>+            modifierState = xevent.xmotion.state;
>+
>+            event.time = xevent.xmotion.time;
>+        }
>+        else {
>+#endif /* MOZ_X11 */
>+            event.refPoint.x = nscoord(aEvent->x);
>+            event.refPoint.y = nscoord(aEvent->y);
>+
>+            modifierState = aEvent->state;
>+
>+            event.time = aEvent->time;
>+#ifdef MOZ_X11
>+        }
> #endif /* MOZ_X11 */

synthEvent can only be true when MOZ_X11 is defined and
GDK_IS_X11_DISPLAY(gdk_display_get_default()), so most of this is not needed.
Attachment #8566469 - Flags: feedback?(karlt) → feedback+
Attached patch wayland v.2 (obsolete) — Splinter Review
Thanks, there's an updated one. 

Another check added tp nsWindow::HasPendingInputEvent() which was missing in the original patch.

> XInitThreads() needs to be called before Xlib is used.
> 
> I wonder whether it would be tidier to set mDisableRemote in the
> MOZ_WIDGET_GTK block above and then use
> mDisableRemote = mDisableRemove && e && *e;

I see. I think the correct construction is (mDisableRemove || (e && *e)).

> If Wayland uses another mechanism, then initialize mNetWorkareaAtom to
> something so that it won't match in root_window_event_filter.

It does not use _NET_WORKAREA so I initialized it to 0 in class constructor.
Attachment #8566469 - Attachment is obsolete: true
Attachment #8572611 - Flags: review?(karlt)
Comment on attachment 8572611 [details] [diff] [review]
wayland v.2

(In reply to Martin Stránský from comment #19)
> I see. I think the correct construction is (mDisableRemove || (e && *e)).

Ah, yes.  Thank you.

>+  if (!GDK_IS_X11_DISPLAY(mGdkDisplay))
>+    mDisableRemote = true;
>+# endif

Please add {} on this conditional block, which is the style we're moving
towards (though I don't mind missing {} around jump statements such as
return).

And please remove the space in "# endif" so that it aligns with the #if above.

>+STUB(gdk_cairo_create)

I don't see this used outside nptest_gtk2.cpp, where the stub should not be
necessary.

Please remove, or is a preprocessing change causing something to depend on
this?
Attachment #8572611 - Flags: review?(karlt) → review+
Attached patch wayland for check-in (obsolete) — Splinter Review
Thanks, there's the one for check-in. try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=04dd5d53450f

gdk_cairo_create is a leftover from my experiments with nsWindow::GetThebesSurface() which need an update but I'd prefer to leave it to another patch.
Attachment #8572611 - Attachment is obsolete: true
Whiteboard: [ leave open for more patches ]
Whiteboard: [ leave open for more patches ] → [ leave open for tracking ]
Please file new bugs, blocking this one, for other patches.  A single Bugzilla bug is not good at managing multiple threads, but multiple bugs can organize related information.
Keywords: leave-open
Attached patch WIP patch (obsolete) — Splinter Review
There's a followup patch for non X11 bacekends (tested on broadway and wayland).
I'd like to discuss it here and we can divide it to separate bugs then. It address those issues:

- draw to container window - we can't draw on toplevel window on wayland because it's bigger than the widget and it's used to render widget shadow. So I use mozcontainer window for rendering.
- create gfxSurface (in GetThebesSurface) as a wrapped one. Is there any better way? Off screen surface or something different?
- cairo subsurfaces fixes - non-X11 gtk uses cairo subsurface types which are tricky - reported as images but image backend mostly fails. 
- disables GXL support
- disables OMTC (is it supposed to work somehow on wayland?)
- try to detect propper backend from ENV variables

Thanks!
Attachment #8643709 - Flags: feedback?(karlt)
Just FYI, switching over to GTK+3 seems to be coming soon, see e.g. Bug 1186748.
Sorry, Bug 1186003 is the one. We have GTK+3 in Fx 42+.
(In reply to Martin Stránský from comment #25)
> - disables OMTC (is it supposed to work somehow on wayland?)

What's broken with OMTC? Disabling it isn't going to be an option.
Comment on attachment 8643709 [details] [diff] [review]
WIP patch

(In reply to Martin Stránský from comment #25)
> - draw to container window - we can't draw on toplevel window on wayland
> because it's bigger than the widget and it's used to render widget shadow.
> So I use mozcontainer window for rendering.

This makes sense.  It is more a CSD issue than a Wayland issue.  The issue
exists on X11 also (bug 1195002).  I assume Wayland doesn't force compositors
to depend on clients for decorations.

> - create gfxSurface (in GetThebesSurface) as a wrapped one.

That seems reasonable to me.  I'm not familiar with the drawing model though.
Is a swap-buffers required after drawing?

> - cairo subsurfaces fixes - non-X11 gtk uses cairo subsurface types which
> are tricky - reported as images but image backend mostly fails.

I don't know anything about that.

These things are going to be easier to review in conceptual chunks with
reasoning behind them.  If this is working around a cairo bug, then we need to
consider why this can't be fixed in cairo.  I suspect we have time before
the Wayland port is ready for production.

> - disables GXL support

Haven't really looked at that, but that can be handled separately, I assume.

> - disables OMTC (is it supposed to work somehow on wayland?)

Currently GetThebesSurface() is used on the compositor thread which is an
existing bug because GDK is not designed for multi-thread access.

For OMTC, I guess it is possible to fetch the surface on the main thread and
then return it when requested on the compositor thread.

> - try to detect propper backend from ENV variables

I haven't looked into details there either but that is also an isolated change.
Attachment #8643709 - Flags: feedback?(karlt) → feedback+
Duplicate of this bug: 1190183
Blocks: 1228424
I tested latest nightly and works fine on Wayland, with patches from Bug 1215085 Bug 1215088 and Bug 1215104. So we need just 3 extra patches to make Firefox work on Wayland.
Attached patch patchSplinter Review
Complete Wayland patch for latest trunk.
Attachment #8573204 - Attachment is obsolete: true
Attachment #8643709 - Attachment is obsolete: true
Depends on: 1281425
Archlinux 64bit. With the above patch Firefox is still broken on Wayland+Weston. E.g content in Firefox window is updated only after focusing on another window and focusing back to the Firefox window. Off Main Thread Compositing is disabled.
I created a package which applies the patches to the 47.0 sources: https://aur.archlinux.org/packages/firefox-wayland
Unfortunately this doesn't work yet ... I guess I have apply this patch to trunk?
I started firefox with: GDK_BACKEND=wayland firefox
Working packages are here but that's Fedora builds (wayland by default, EGL enabled):
https://copr.fedorainfracloud.org/coprs/stransky/firefox-wayland

The missing rendering content is caused by enabled OMTC, you need to set:
layers.offmainthreadcomposition.force-disabled:true on trunk.
Depends on: 1282015
>>Working packages are here but that's Fedora builds (wayland by default, EGL enabled):

Tried these as well, same issue.

>>The missing rendering content is caused by enabled OMTC, you need to set:

OMTC is disabled, also content is not missing but is drawn only on window blur. For example, content is updated after focusing on another window and focusing back to the Firefox window. Also, clicking in the addressbar does not show the cursor, but clicking on the menu and bookmarks icon does show menus.

mozconfig

. $topsrcdir/browser/config/mozconfig

ac_add_options --enable-default-toolkit=cairo-gtk3
ac_add_options --with-system-nspr
ac_add_options --with-system-nss
ac_add_options --enable-system-sqlite
ac_add_options --disable-system-cairo
ac_add_options --enable-system-ffi
ac_add_options --disable-debug
ac_add_options --enable-optimize="-g -O2"
ac_add_options --disable-crashreporter
ac_add_options --disable-tests
ac_add_options --without-system-jpeg
ac_add_options --with-system-libvpx
ac_add_options --with-system-icu
ac_add_options --enable-release
ac_add_options --enable-pie
ac_add_options --with-gl-provider=EGL

export BUILD_OFFICIAL=1
export MOZILLA_OFFICIAL=1
export MOZILLA_TELEMETRY=0
mk_add_options BUILD_OFFICIAL=1
mk_add_options MOZILLA_OFFICIAL=1
The nightly on Wayland should now work on Archlinux after these steps.

- gfx/thebes/gfxPlatform.cpp - find LayersOffMainThreadCompositionForceDisabled( and add return false; to  the  top of the function. Setting layers.offmainthreadcomposition.force-disabled instead did not work for me.
- Uncheck "Enable multi-process Nightly" in the preferences and restart. Otherwise, not configuration pages will be empty.
- When clicking some icons or items in the menu - e.g Zoom In, you have to hold Ctrl.
Depends on: 1283055
No longer blocks: 1215104
Depends on: 1215104
Depends on: 726479
all y bags when i start firefox-trunk without xwayland

(firefox-trunk:3588): Gtk-WARNING **: Failed to parse 
/home/x/.config/gtk-3.0/se ttings.ini: Key file does not start with a 
group 

(firefox-trunk:3588): Gtk-WARNING **: Failed to parse/home/x/.config/gtk-3.0/se ttings.ini: Key file does not start with a 
group 

(firefox-trunk:3588): GConf-WARNING **: Client failed to connect 
to the D-BUS da emon: Unable to autolaunch a dbus-daemon without a 
$DISPLAY for X11 

(firefox-trunk:3588): GConf-WARNING **: Client failed 
to connect to the D-BUS da emon: Unable to autolaunch a dbus-daemon 
without a $DISPLAY for X11 Ñибка ÑегменÑиÑованиÑ


 [Child 4679] ###!!! ABORT: Aborting on channel error.: file 
/build/firefox-tru 
nk-_hskEs/firefox-trunk-50.0~a1~hg20160708r304097/ipc/glue/MessageChannel.cpp, 
l ine 2053 


(firefox-trunk:4805): Gtk-WARNING **: Failed to parse 
/home/x/.config/gtk-3.0/se ttings.ini: Key file does not have group 
'Settings'
This isn't directly related to this bug in particular but I have tried running a regular firefox build in a wayland session using Xwayland. Resizing the window causes the black box window to be drawn behind firefox. It disappears when resizing is done.
Can that be fixed? This alone would be a huge usability improvement.
Depends on: 1299083
Blocks: gem
Depends on: 1306613
@Martin Stránský: Thank you for maintaining this repo! I tried to make a buildscript for the ArchLinux user repository here: https://aur.archlinux.org/packages/firefox-wayland-git

Unfortunately I get a compile error, maybe you know why:
> /usr/bin/g++ -std=gnu++11 -o Unified_cpp_js_src9.o -c  -I/home/onny/projects/firefox-wayland-git/src/gecko-dev/obj-x86_64-pc-linux-gnu/dist/system_wrappers -include /home/onny/projects/firefox-wayland-git/src/gecko-dev/config/gcc_hidden.h -DNDEBUG=1 -DTRIMMED=1 -DENABLE_BINARYDATA -DENABLE_SIMD -DENABLE_SHARED_ARRAY_BUFFER -DEXPORT_JS_API -DJS_HAS_CTYPES '-DDLL_PREFIX="lib"' '-DDLL_SUFFIX=".so"' -I/home/onny/projects/firefox-wayland-git/src/gecko-dev/js/src -I/home/onny/projects/firefox-wayland-git/src/gecko-dev/obj-x86_64-pc-linux-gnu/js/src  -I/home/onny/projects/firefox-wayland-git/src/gecko-dev/obj-x86_64-pc-linux-gnu/dist/include  -I/usr/include/nspr        -fPIC  -DMOZILLA_CLIENT -include /home/onny/projects/firefox-wayland-git/src/gecko-dev/obj-x86_64-pc-linux-gnu/js/src/js-confdefs.h -MD -MP -MF .deps/Unified_cpp_js_src9.o.pp -D_FORTIFY_SOURCE=2 -O2 -Wall -Wc++11-compat -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof -Wc++14-compat -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4 -fno-delete-null-pointer-checks -fno-schedule-insns2 -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -pthread -pipe  -g -freorder-blocks -O3 -fomit-frame-pointer  -I/usr/lib/libffi-3.2.1/include -Wno-shadow -Werror=format  /home/onny/projects/firefox-wayland-git/src/gecko-dev/obj-x86_64-pc-linux-gnu/js/src/Unified_cpp_js_src9.cpp
> libjs_static.a
> rm -f libjs_static.a libjs_static.a.desc
> /home/onny/projects/firefox-wayland-git/src/gecko-dev/obj-x86_64-pc-linux-gnu/_virtualenv/bin/python /home/onny/projects/firefox-wayland-git/src/gecko-dev/config/expandlibs_exec.py --extract -- ar crs libjs_static.a RegExp.o CTypes.o Library.o Parser.o StoreBuffer.o ExecutableAllocatorPosix.o Disassembler-x86-shared.o jsarray.o jsatom.o jsdtoa.o jsmath.o jsutil.o pm_linux.o ConditionVariable.o MutexImpl.o Thread.o Initialization.o TraceLogging.o TraceLoggingGraph.o TraceLoggingTypes.o Unified_cpp_js_src0.o Unified_cpp_js_src1.o Unified_cpp_js_src10.o Unified_cpp_js_src11.o Unified_cpp_js_src12.o Unified_cpp_js_src13.o Unified_cpp_js_src14.o Unified_cpp_js_src15.o Unified_cpp_js_src16.o Unified_cpp_js_src17.o Unified_cpp_js_src18.o Unified_cpp_js_src19.o Unified_cpp_js_src2.o Unified_cpp_js_src20.o Unified_cpp_js_src21.o Unified_cpp_js_src22.o Unified_cpp_js_src23.o Unified_cpp_js_src24.o Unified_cpp_js_src25.o Unified_cpp_js_src26.o Unified_cpp_js_src27.o Unified_cpp_js_src28.o Unified_cpp_js_src29.o Unified_cpp_js_src3.o Unified_cpp_js_src30.o Unified_cpp_js_src31.o Unified_cpp_js_src32.o Unified_cpp_js_src33.o Unified_cpp_js_src34.o Unified_cpp_js_src35.o Unified_cpp_js_src36.o Unified_cpp_js_src37.o Unified_cpp_js_src38.o Unified_cpp_js_src39.o Unified_cpp_js_src4.o Unified_cpp_js_src40.o Unified_cpp_js_src5.o Unified_cpp_js_src6.o Unified_cpp_js_src7.o Unified_cpp_js_src8.o Unified_cpp_js_src9.o ../../config/external/ffi/libconfig_external_ffi.a ../../config/external/icu/libicu.a ../../config/external/fdlibm/libfdlibm.a ../../config/external/nspr/libnspr.a ../../config/external/zlib/libzlib.a 
> make[3]: *** [/home/onny/projects/firefox-wayland-git/src/gecko-dev/config/recurse.mk:33: compile] Error 2
> make[3]: Leaving directory '/home/onny/projects/firefox-wayland-git/src/gecko-dev/obj-x86_64-pc-linux-gnu'
> make[2]: *** [/home/onny/projects/firefox-wayland-git/src/gecko-dev/config/rules.mk:523: default] Error 2
> make[2]: Leaving directory '/home/onny/projects/firefox-wayland-git/src/gecko-dev/obj-x86_64-pc-linux-gnu'
> make[1]: *** [/home/onny/projects/firefox-wayland-git/src/gecko-dev/client.mk:415: realbuild] Error 2
> make[1]: Leaving directory '/home/onny/projects/firefox-wayland-git/src/gecko-dev'
> make: *** [client.mk:170: build] Error 2
> ==> ERROR: A failure occurred in build().
>     Aborting...
It looks like this command is failing:
> Executing: ar crs CTypes.o ConditionVariable.o Disassembler-x86-shared.o ExecutableAllocatorPosix.o Initialization.o Library.o MutexImpl.o Parser.o RegExp.o StoreBuffer.o Thread.o TraceLogging.o TraceLoggingGraph.o TraceLoggingTypes.o Unified_cpp_js_src0.o Unified_cpp_js_src1.o Unified_cpp_js_src10.o Unified_cpp_js_src11.o Unified_cpp_js_src12.o Unified_cpp_js_src13.o Unified_cpp_js_src14.o Unified_cpp_js_src15.o Unified_cpp_js_src16.o Unified_cpp_js_src17.o Unified_cpp_js_src18.o Unified_cpp_js_src19.o Unified_cpp_js_src2.o Unified_cpp_js_src20.o Unified_cpp_js_src21.o Unified_cpp_js_src22.o Unified_cpp_js_src23.o Unified_cpp_js_src24.o Unified_cpp_js_src25.o Unified_cpp_js_src26.o Unified_cpp_js_src27.o Unified_cpp_js_src28.o Unified_cpp_js_src29.o Unified_cpp_js_src3.o Unified_cpp_js_src30.o Unified_cpp_js_src31.o Unified_cpp_js_src32.o Unified_cpp_js_src33.o Unified_cpp_js_src34.o Unified_cpp_js_src35.o Unified_cpp_js_src36.o Unified_cpp_js_src37.o Unified_cpp_js_src38.o Unified_cpp_js_src39.o Unified_cpp_js_src4.o Unified_cpp_js_src40.o Unified_cpp_js_src5.o Unified_cpp_js_src6.o Unified_cpp_js_src7.o Unified_cpp_js_src8.o Unified_cpp_js_src9.o jsarray.o jsatom.o jsdtoa.o jsmath.o jsutil.o pm_linux.o tmpj6OdrR/e_acos.o tmpj6OdrR/e_acosh.o tmpj6OdrR/e_asin.o tmpj6OdrR/e_atan2.o tmpj6OdrR/e_atanh.o tmpj6OdrR/e_cosh.o tmpj6OdrR/e_exp.o tmpj6OdrR/e_hypot.o tmpj6OdrR/e_log.o tmpj6OdrR/e_log10.o tmpj6OdrR/e_log2.o tmpj6OdrR/e_pow.o tmpj6OdrR/e_sinh.o tmpj6OdrR/e_sqrt.o tmpj6OdrR/k_exp.o tmpj6OdrR/s_asinh.o tmpj6OdrR/s_atan.o tmpj6OdrR/s_cbrt.o tmpj6OdrR/s_ceil.o tmpj6OdrR/s_ceilf.o tmpj6OdrR/s_copysign.o tmpj6OdrR/s_expm1.o tmpj6OdrR/s_fabs.o tmpj6OdrR/s_floor.o tmpj6OdrR/s_floorf.o tmpj6OdrR/s_log1p.o tmpj6OdrR/s_nearbyint.o tmpj6OdrR/s_rint.o tmpj6OdrR/s_rintf.o tmpj6OdrR/s_scalbn.o tmpj6OdrR/s_tanh.o tmpj6OdrR/s_trunc.o tmpj6OdrR/s_truncf.o RegExp.o CTypes.o Library.o Parser.o StoreBuffer.o ExecutableAllocatorPosix.o Disassembler-x86-shared.o jsarray.o jsatom.o jsdtoa.o jsmath.o jsutil.o pm_linux.o ConditionVariable.o MutexImpl.o Thread.o Initialization.o TraceLogging.o TraceLoggingGraph.o TraceLoggingTypes.o Unified_cpp_js_src0.o Unified_cpp_js_src1.o Unified_cpp_js_src10.o Unified_cpp_js_src11.o Unified_cpp_js_src12.o Unified_cpp_js_src13.o Unified_cpp_js_src14.o Unified_cpp_js_src15.o Unified_cpp_js_src16.o Unified_cpp_js_src17.o Unified_cpp_js_src18.o Unified_cpp_js_src19.o Unified_cpp_js_src2.o Unified_cpp_js_src20.o Unified_cpp_js_src21.o Unified_cpp_js_src22.o Unified_cpp_js_src23.o Unified_cpp_js_src24.o Unified_cpp_js_src25.o Unified_cpp_js_src26.o Unified_cpp_js_src27.o Unified_cpp_js_src28.o Unified_cpp_js_src29.o Unified_cpp_js_src3.o Unified_cpp_js_src30.o Unified_cpp_js_src31.o Unified_cpp_js_src32.o Unified_cpp_js_src33.o Unified_cpp_js_src34.o Unified_cpp_js_src35.o Unified_cpp_js_src36.o Unified_cpp_js_src37.o Unified_cpp_js_src38.o Unified_cpp_js_src39.o Unified_cpp_js_src4.o Unified_cpp_js_src40.o Unified_cpp_js_src5.o Unified_cpp_js_src6.o Unified_cpp_js_src7.o Unified_cpp_js_src8.o Unified_cpp_js_src9.o ../../modules/fdlibm/src/e_acos.o ../../modules/fdlibm/src/e_acosh.o ../../modules/fdlibm/src/e_asin.o ../../modules/fdlibm/src/e_atan2.o ../../modules/fdlibm/src/e_atanh.o ../../modules/fdlibm/src/e_cosh.o ../../modules/fdlibm/src/e_exp.o ../../modules/fdlibm/src/e_hypot.o ../../modules/fdlibm/src/e_log.o ../../modules/fdlibm/src/e_log10.o ../../modules/fdlibm/src/e_log2.o ../../modules/fdlibm/src/e_pow.o ../../modules/fdlibm/src/e_sinh.o ../../modules/fdlibm/src/e_sqrt.o ../../modules/fdlibm/src/k_exp.o ../../modules/fdlibm/src/s_asinh.o ../../modules/fdlibm/src/s_atan.o ../../modules/fdlibm/src/s_cbrt.o ../../modules/fdlibm/src/s_ceil.o ../../modules/fdlibm/src/s_ceilf.o ../../modules/fdlibm/src/s_copysign.o ../../modules/fdlibm/src/s_expm1.o ../../modules/fdlibm/src/s_fabs.o ../../modules/fdlibm/src/s_floor.o ../../modules/fdlibm/src/s_floorf.o ../../modules/fdlibm/src/s_log1p.o ../../modules/fdlibm/src/s_nearbyint.o ../../modules/fdlibm/src/s_rint.o ../../modules/fdlibm/src/s_rintf.o ../../modules/fdlibm/src/s_scalbn.o ../../modules/fdlibm/src/s_tanh.o ../../modules/fdlibm/src/s_trunc.o ../../modules/fdlibm/src/s_truncf.o
> ar: CTypes.o: File format not recognized
I would really appreciate any hint :)
Thanks!
Further ...
> % file CTypes.o                                                                :(
> CTypes.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
Following files doesn't seem to exists:
>  ../../config/external/ffi/libconfig_external_ffi.a ../../config/external/icu/libicu.a ../../config/external/fdlibm/libfdlibm.a ../../config/external/nspr/libnspr.a ../../config/external/zlib/libzlib.a 
So this command works fine
> ar crs libjs_static.a RegExp.o CTypes.o Library.o Parser.o StoreBuffer.o ExecutableAllocatorPosix.o Disassembler-x86-shared.o jsarray.o jsatom.o jsdtoa.o jsmath.o jsutil.o pm_linux.o ConditionVariable.o MutexImpl.o Thread.o Initialization.o TraceLogging.o TraceLoggingGraph.o TraceLoggingTypes.o Unified_cpp_js_src0.o Unified_cpp_js_src1.o Unified_cpp_js_src10.o Unified_cpp_js_src11.o Unified_cpp_js_src12.o Unified_cpp_js_src13.o Unified_cpp_js_src14.o Unified_cpp_js_src15.o Unified_cpp_js_src16.o Unified_cpp_js_src17.o Unified_cpp_js_src18.o Unified_cpp_js_src19.o Unified_cpp_js_src2.o Unified_cpp_js_src20.o Unified_cpp_js_src21.o Unified_cpp_js_src22.o Unified_cpp_js_src23.o Unified_cpp_js_src24.o Unified_cpp_js_src25.o Unified_cpp_js_src26.o Unified_cpp_js_src27.o Unified_cpp_js_src28.o Unified_cpp_js_src29.o Unified_cpp_js_src3.o Unified_cpp_js_src30.o Unified_cpp_js_src31.o Unified_cpp_js_src32.o Unified_cpp_js_src33.o Unified_cpp_js_src34.o Unified_cpp_js_src35.o Unified_cpp_js_src36.o Unified_cpp_js_src37.o Unified_cpp_js_src38.o Unified_cpp_js_src39.o Unified_cpp_js_src4.o Unified_cpp_js_src40.o Unified_cpp_js_src5.o Unified_cpp_js_src6.o Unified_cpp_js_src7.o Unified_cpp_js_src8.o Unified_cpp_js_src9.o
Where as this command, from the build script, fails
> % /home/onny/projects/firefox-wayland-git/src/gecko-dev/obj-x86_64-pc-linux-gnu/_virtualenv/bin/python /home/onny/projects/firefox-wayland-git/src/gecko-dev/config/expandlibs_exec.py --extract -- ar crs libjs_static.a RegExp.o CTypes.o Library.o Parser.o StoreBuffer.o ExecutableAllocatorPosix.o Disassembler-x86-shared.o jsarray.o jsatom.o jsdtoa.o jsmath.o jsutil.o pm_linux.o ConditionVariable.o MutexImpl.o Thread.o Initialization.o TraceLogging.o TraceLoggingGraph.o TraceLoggingTypes.o Unified_cpp_js_src0.o Unified_cpp_js_src1.o Unified_cpp_js_src10.o Unified_cpp_js_src11.o Unified_cpp_js_src12.o Unified_cpp_js_src13.o Unified_cpp_js_src14.o Unified_cpp_js_src15.o Unified_cpp_js_src16.o Unified_cpp_js_src17.o Unified_cpp_js_src18.o Unified_cpp_js_src19.o Unified_cpp_js_src2.o Unified_cpp_js_src20.o Unified_cpp_js_src21.o Unified_cpp_js_src22.o Unified_cpp_js_src23.o Unified_cpp_js_src24.o Unified_cpp_js_src25.o Unified_cpp_js_src26.o Unified_cpp_js_src27.o Unified_cpp_js_src28.o Unified_cpp_js_src29.o Unified_cpp_js_src3.o Unified_cpp_js_src30.o Unified_cpp_js_src31.o Unified_cpp_js_src32.o Unified_cpp_js_src33.o Unified_cpp_js_src34.o Unified_cpp_js_src35.o Unified_cpp_js_src36.o Unified_cpp_js_src37.o Unified_cpp_js_src38.o Unified_cpp_js_src39.o Unified_cpp_js_src4.o Unified_cpp_js_src40.o Unified_cpp_js_src5.o Unified_cpp_js_src6.o Unified_cpp_js_src7.o Unified_cpp_js_src8.o Unified_cpp_js_src9.o ../../config/external/ffi/libconfig_external_ffi.a ../../config/external/icu/libicu.a ../../config/external/fdlibm/libfdlibm.a ../../config/external/nspr/libnspr.a ../../config/external/zlib/libzlib.a
> Executing: ar crs CTypes.o ConditionVariable.o Disassembler-x86-shared.o ExecutableAllocatorPosix.o Initialization.o Library.o MutexImpl.o Parser.o RegExp.o StoreBuffer.o Thread.o TraceLogging.o TraceLoggingGraph.o TraceLoggingTypes.o Unified_cpp_js_src0.o Unified_cpp_js_src1.o Unified_cpp_js_src10.o Unified_cpp_js_src11.o Unified_cpp_js_src12.o Unified_cpp_js_src13.o Unified_cpp_js_src14.o Unified_cpp_js_src15.o Unified_cpp_js_src16.o Unified_cpp_js_src17.o Unified_cpp_js_src18.o Unified_cpp_js_src19.o Unified_cpp_js_src2.o Unified_cpp_js_src20.o Unified_cpp_js_src21.o Unified_cpp_js_src22.o Unified_cpp_js_src23.o Unified_cpp_js_src24.o Unified_cpp_js_src25.o Unified_cpp_js_src26.o Unified_cpp_js_src27.o Unified_cpp_js_src28.o Unified_cpp_js_src29.o Unified_cpp_js_src3.o Unified_cpp_js_src30.o Unified_cpp_js_src31.o Unified_cpp_js_src32.o Unified_cpp_js_src33.o Unified_cpp_js_src34.o Unified_cpp_js_src35.o Unified_cpp_js_src36.o Unified_cpp_js_src37.o Unified_cpp_js_src38.o Unified_cpp_js_src39.o Unified_cpp_js_src4.o Unified_cpp_js_src40.o Unified_cpp_js_src5.o Unified_cpp_js_src6.o Unified_cpp_js_src7.o Unified_cpp_js_src8.o Unified_cpp_js_src9.o jsarray.o jsatom.o jsdtoa.o jsmath.o jsutil.o pm_linux.o tmpRC5Q8O/e_acos.o tmpRC5Q8O/e_acosh.o tmpRC5Q8O/e_asin.o tmpRC5Q8O/e_atan2.o tmpRC5Q8O/e_atanh.o tmpRC5Q8O/e_cosh.o tmpRC5Q8O/e_exp.o tmpRC5Q8O/e_hypot.o tmpRC5Q8O/e_log.o tmpRC5Q8O/e_log10.o tmpRC5Q8O/e_log2.o tmpRC5Q8O/e_pow.o tmpRC5Q8O/e_sinh.o tmpRC5Q8O/e_sqrt.o tmpRC5Q8O/k_exp.o tmpRC5Q8O/s_asinh.o tmpRC5Q8O/s_atan.o tmpRC5Q8O/s_cbrt.o tmpRC5Q8O/s_ceil.o tmpRC5Q8O/s_ceilf.o tmpRC5Q8O/s_copysign.o tmpRC5Q8O/s_expm1.o tmpRC5Q8O/s_fabs.o tmpRC5Q8O/s_floor.o tmpRC5Q8O/s_floorf.o tmpRC5Q8O/s_log1p.o tmpRC5Q8O/s_nearbyint.o tmpRC5Q8O/s_rint.o tmpRC5Q8O/s_rintf.o tmpRC5Q8O/s_scalbn.o tmpRC5Q8O/s_tanh.o tmpRC5Q8O/s_trunc.o tmpRC5Q8O/s_truncf.o RegExp.o CTypes.o Library.o Parser.o StoreBuffer.o ExecutableAllocatorPosix.o Disassembler-x86-shared.o jsarray.o jsatom.o jsdtoa.o jsmath.o jsutil.o pm_linux.o ConditionVariable.o MutexImpl.o Thread.o Initialization.o TraceLogging.o TraceLoggingGraph.o TraceLoggingTypes.o Unified_cpp_js_src0.o Unified_cpp_js_src1.o Unified_cpp_js_src10.o Unified_cpp_js_src11.o Unified_cpp_js_src12.o Unified_cpp_js_src13.o Unified_cpp_js_src14.o Unified_cpp_js_src15.o Unified_cpp_js_src16.o Unified_cpp_js_src17.o Unified_cpp_js_src18.o Unified_cpp_js_src19.o Unified_cpp_js_src2.o Unified_cpp_js_src20.o Unified_cpp_js_src21.o Unified_cpp_js_src22.o Unified_cpp_js_src23.o Unified_cpp_js_src24.o Unified_cpp_js_src25.o Unified_cpp_js_src26.o Unified_cpp_js_src27.o Unified_cpp_js_src28.o Unified_cpp_js_src29.o Unified_cpp_js_src3.o Unified_cpp_js_src30.o Unified_cpp_js_src31.o Unified_cpp_js_src32.o Unified_cpp_js_src33.o Unified_cpp_js_src34.o Unified_cpp_js_src35.o Unified_cpp_js_src36.o Unified_cpp_js_src37.o Unified_cpp_js_src38.o Unified_cpp_js_src39.o Unified_cpp_js_src4.o Unified_cpp_js_src40.o Unified_cpp_js_src5.o Unified_cpp_js_src6.o Unified_cpp_js_src7.o Unified_cpp_js_src8.o Unified_cpp_js_src9.o ../../modules/fdlibm/src/e_acos.o ../../modules/fdlibm/src/e_acosh.o ../../modules/fdlibm/src/e_asin.o ../../modules/fdlibm/src/e_atan2.o ../../modules/fdlibm/src/e_atanh.o ../../modules/fdlibm/src/e_cosh.o ../../modules/fdlibm/src/e_exp.o ../../modules/fdlibm/src/e_hypot.o ../../modules/fdlibm/src/e_log.o ../../modules/fdlibm/src/e_log10.o ../../modules/fdlibm/src/e_log2.o ../../modules/fdlibm/src/e_pow.o ../../modules/fdlibm/src/e_sinh.o ../../modules/fdlibm/src/e_sqrt.o ../../modules/fdlibm/src/k_exp.o ../../modules/fdlibm/src/s_asinh.o ../../modules/fdlibm/src/s_atan.o ../../modules/fdlibm/src/s_cbrt.o ../../modules/fdlibm/src/s_ceil.o ../../modules/fdlibm/src/s_ceilf.o ../../modules/fdlibm/src/s_copysign.o ../../modules/fdlibm/src/s_expm1.o ../../modules/fdlibm/src/s_fabs.o ../../modules/fdlibm/src/s_floor.o ../../modules/fdlibm/src/s_floorf.o ../../modules/fdlibm/src/s_log1p.o ../../modules/fdlibm/src/s_nearbyint.o ../../modules/fdlibm/src/s_rint.o ../../modules/fdlibm/src/s_rintf.o ../../modules/fdlibm/src/s_scalbn.o ../../modules/fdlibm/src/s_tanh.o ../../modules/fdlibm/src/s_trunc.o ../../modules/fdlibm/src/s_truncf.o
> ar: CTypes.o: File format not recognized
This is slightly out-of-topic.  Martin Stránský, could you rebase your repo to https://hg.mozilla.org/mozilla-central/rev/ebcbf47a83e7 or backport this changeset? That fixes building on Arch Linux (partially).
Summary: Make Firefox work as well with Wayland (without X) as with just X → Firefox Wayland port
Depends on: 1336047
Depends on: 1336048
Depends on: 1336071
Depends on: 1337369
Duplicate of this bug: 1332857
I created a Flatpak of @stranskys Firefox Wayland version, so it is easy to try out on all x64 Linux systems without having to compile it https://project-insanity.org/blog/2017/02/14/try-out-firefox-on-wayland-easily/
Depends on: 1339916
Depends on: 1339917
Depends on: 1339920
Depends on: 1345666
Depends on: 1348310
Hi, I'm working on https://github.com/mozilla-japan/gecko-dev/commits/esr52-wayland-stransky to backport Stránský's patches in ESR52 branch.
Now, this repo is still WIP.
Depends on: 1348990
The github repo (https://github.com/stransky/gecko-dev) has been synced with latest trunk and contains all available wayland patches. There are tree pre-built options if you're interested in testing the Wayland builds:

Flatpak - https://firefox-flatpak.mojefedora.cz/
COPR repo - https://copr.fedorainfracloud.org/coprs/stransky/firefox-wayland/
src.rpm - https://stransky.fedorapeople.org/

I'm also very interested in any crashes / bugs, please report here or at bugzilla.redhat.com.
(In reply to Martin Stránský from comment #55)
> I'm also very interested in any crashes / bugs, please report here or at
> bugzilla.redhat.com.

Thanks for this Martin.

Flatpak Wayland build crashes regularly for me. However building from your source using the flatpak mozconfig is more stable, so it may be a flatpak issue?

The one major issue I can see with my built version is that the menu when right-clicking a tab is blank (grey rather than white). All other right-click menus appear OK though.
(In reply to tarkasteve from comment #56)
> (In reply to Martin Stránský from comment #55)
> > I'm also very interested in any crashes / bugs, please report here or at
> > bugzilla.redhat.com.
> 
> Thanks for this Martin.
> 
> Flatpak Wayland build crashes regularly for me. However building from your
> source using the flatpak mozconfig is more stable, so it may be a flatpak
> issue?

Maybe, backtrace may be more helpful here although flatpak debugging is troublesome. I'd leave that for further investigation.

> The one major issue I can see with my built version is that the menu when
> right-clicking a tab is blank (grey rather than white). All other
> right-click menus appear OK though.

That's caused by missing wl_surface of associated GdkWindow. Needs to be fixed by better popup/seat management.
(In reply to Martin Stránský from comment #55)

I'm seeing issues in HiDPI mode. The window content is scaled outside the window border:

    http://i.imgur.com/zrJXYT1.jpg

The parts outside the window area are unresponsive, but I can 'control' the UI by clicking inside the windowed area (i.e. the content is scaled up but the input area is not.

Debian Stretch / Gnome 3.22 / Intel HD.
tarkasteve: That appears to be the same issue I reported in https://bugzilla.mozilla.org/show_bug.cgi?id=1345666
Hi, testing latest flatpak version on my Debian Sid GNOME-Wayland 64 bits, I'm not able to customize Firefox using the dedicated button in the hamburger menu : nor the hamburger menu nor the toolbar can be customized.
Thanks !
(In reply to Martin Stránský from comment #55)

Paste (Ctrl-V) in a text box or area causes immediate lockup consistently. This is building from the firefox-wayland-55.7-1 using a production-esque .mozconfig.
(In reply to tarkasteve from comment #61)
> (In reply to Martin Stránský from comment #55)
> 
> Paste (Ctrl-V) in a text box or area causes immediate lockup consistently.
> This is building from the firefox-wayland-55.7-1 using a production-esque
> .mozconfig.

Please file a new bug for that and assign it to me, this one is for tracking purpose only. Thanks!
Trying create a package for ArchLinux including your patches (https://aur.archlinux.org/packages/firefox-wayland-git). Unfortunately I this error:
> /home/onny/projects/firefox-wayland-git/src/gecko-dev/obj-x86_64-pc-linux-gnu/_virtualenv/bin/python -m mozbuild.action.file_generate /home/onny/projects/firefox-wayland-git/src/gecko-dev/build/variables.py source_repo_header source-repo.h .deps/source-repo.h.pp
> Traceback (most recent call last):
>  File "/usr/lib64/python2.7/runpy.py", line 174, in _run_module_as_main
>    "__main__", fname, loader, pkg_name)
>  File "/usr/lib64/python2.7/runpy.py", line 72, in _run_code
>    exec code in run_globals
>  File "/home/onny/projects/firefox-wayland-git/src/gecko-dev/python/mozbuild/mozbuild/action/file_generate.py", line 108, in <module>
>    sys.exit(main(sys.argv[1:]))
>  File "/home/onny/projects/firefox-wayland-git/src/gecko-dev/python/mozbuild/mozbuild/action/file_generate.py", line 63, in main
>    ret = module.__dict__[method](output, *args.additional_arguments)
>  File "/home/onny/projects/firefox-wayland-git/src/gecko-dev/build/variables.py", line 86, in source_repo_header
>    raise Exception('could not resolve changeset; '
> Exception: could not resolve changeset; try setting MOZ_SOURCE_CHANGESET
I guess it's not related to your patches but do you know how to fix this?
Depends on: 1383156
(In reply to Jonas Heinrich from comment #63)
> > Exception: could not resolve changeset; try setting MOZ_SOURCE_CHANGESET
> I guess it's not related to your patches but do you know how to fix this?

build/variables.py doesn't support getting the source changeset from a git checkout.  So you can build from an hg checkout, or you can set MOZ_SOURCE_CHANGESET.
Depends on: 1396101
Depends on: 1409707
Depends on: 1409716
A few pointers for others trying to use and compile this branch (as of Nov 2017):

1. native compile on armhf:
* runs out of memory (with 2GB RAM): use `ac_add_options --disable-debug-symbols`
* fails because armcpudetect is defined twice (libvpx and libaom): use `ac_add_options --disable-av1` to disable libaom
* fails compiling webrtc: use `ac_add_options --disable-webrtc`

2. firefox segmentation fault on start
* no idea why, but using `firefox --no-remote` works

3. could not get WebGL working
* for some reason, EGL_DEFAULT_DISPLAY was bogus, I had to use this patch:

diff --git a/gfx/gl/GLLibraryEGL.cpp b/gfx/gl/GLLibraryEGL.cpp
index 01bd3a7ff263..5546bd5c9257 100644
--- a/gfx/gl/GLLibraryEGL.cpp
+++ b/gfx/gl/GLLibraryEGL.cpp
@@ -511,7 +511,7 @@ GLLibraryEGL::EnsureInitialized(bool forceAccel, nsACString* const out_failureId
             mIsWARP = true;
         }
     } else {
-        chosenDisplay = GetAndInitDisplay(*this, EGL_DEFAULT_DISPLAY);
+        chosenDisplay = GetAndInitDisplay(*this, ((EGLNativeDisplayType)0));
     }

     if (!chosenDisplay) {

4. video is not working, ffmpeg 3.3.4 installed (libavcodec57 7:3.3.4). any idea how to fix this one?

[Child 1825, MediaPlayback #3] WARNING: Decoder=9d3da380 Decode error: NS_ERROR_DOM_MEDIA_FATAL_ERR (0x806e0005) - mozilla::MediaResult mozilla::FFmpegDataDecoder<57>::InitDecoder(): Couldn't initialise ffmpeg decoder: file /home/odroid/src/firefox/gecko-dev/dom/media/MediaDecoderStateMachine.cpp, line 3350
JavaScript warning: https://www.youtube.com/yts/jsbin/player-vfl8XKJyP/en_US/base.js, line 3233: Error: This error message will be blank when privacy.resistFingerprinting = true.  If it is really necessary, please add it to the whitelist in MediaError::GetMessage: NS_ERROR_DOM_MEDIA_FATAL_ERR (0x806e0005) - mozilla::MediaResult mozilla::FFmpegDataDecoder<57>::InitDecoder(): Couldn't initialise ffmpeg decoder
JavaScript warning: https://www.youtube.com/yts/jsbin/player-vfl8XKJyP/en_US/base.js, line 3233: Error: This error message will be blank when privacy.resistFingerprinting = true.  If it is really necessary, please add it to the whitelist in MediaError::GetMessage: NS_ERROR_DOM_MEDIA_FATAL_ERR (0x806e0005) - mozilla::MediaResult mozilla::FFmpegDataDecoder<57>::InitDecoder(): Couldn't initialise ffmpeg decoder
JavaScript warning: https://www.youtube.com/yts/jsbin/player-vfl8XKJyP/en_US/base.js, line 3233: Error: This error message will be blank when privacy.resistFingerprinting = true.  If it is really necessary, please add it to the whitelist in MediaError::GetMessage: NS_ERROR_DOM_MEDIA_FATAL_ERR (0x806e0005) - mozilla::MediaResult mozilla::FFmpegDataDecoder<57>::InitDecoder(): Couldn't initialise ffmpeg decoder
(In reply to mihailescu2m from comment #65)
> A few pointers for others trying to use and compile this branch (as of Nov
> 2017):
> 
> 1. native compile on armhf:
> * runs out of memory (with 2GB RAM): use `ac_add_options
> --disable-debug-symbols`
> * fails because armcpudetect is defined twice (libvpx and libaom): use
> `ac_add_options --disable-av1` to disable libaom
> * fails compiling webrtc: use `ac_add_options --disable-webrtc`
> 
> 2. firefox segmentation fault on start
> * no idea why, but using `firefox --no-remote` works

Can you please file #BZ for that and attach a backtrace there?
(In reply to Martin Stránský [:stransky] from comment #66)
> Can you please file #BZ for that and attach a backtrace there?

Bug ID #1416186 https://bugzilla.mozilla.org/show_bug.cgi?id=1416186
Trace:
#0  0xb6ec5116 in __libc_do_syscall () at /lib/arm-linux-gnueabihf/libpthread.so.0
#1  0xb6ec4122 in raise () at /lib/arm-linux-gnueabihf/libpthread.so.0
#2  0xb2a13cca in nsProfileLock::FatalSignalHandler(int, siginfo_t*, void*) () at /usr/local/lib/firefox/libxul.so
#3  0xb6c15890 in <signal handler called> () at /lib/arm-linux-gnueabihf/libc.so.6
#4  0xb61960f4 in XChangeProperty () at /usr/lib/arm-linux-gnueabihf/libX11.so.6
#5  0xb27fdff6 in XRemoteClient::DoSendCommandLine(unsigned long, int, char**, char const*, char**, bool*, char const*, char const*) () at /usr/local/lib/firefox/libxul.so
#6  0xb27fe508 in XRemoteClient::SendCommandLine(char const*, char const*, char const*, int, char**, char const*, char**, bool*) () at /usr/local/lib/firefox/libxul.so
#7  0xb2a192ae in XREMain::XRE_mainStartup(bool*) [clone .part.79] () at /usr/local/lib/firefox/libxul.so
#8  0xb6f33ab8 in __stack_chk_guard () at /lib/ld-linux-armhf.so.3

Sorry there are no details because I used --no-debug-symbols to link it on 2GB RAM.
Possible linked to #1359634 or #1360566 and #1360560
Alias: wayland
Assignee: nobody → stransky
Depends on: 1416186
As of 28/11/2017 starting FF (armhf build) fails with `Illegal instruction` error (--screenshot however renders ok):

$ ./objdir-wayland/dist/bin/firefox --no-remote --new-instance --safe-mode --browser --new-window google.com
[Child 5583, Chrome_ChildThread] WARNING: pipe error (20): Connection reset by peer: file /mnt/temp/src/firefox/gecko-dev/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 353
[Child 5583, Chrome_ChildThread] WARNING: pipe error (17): Connection reset by peer: file /mnt/temp/src/firefox/gecko-dev/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 353
[Child 5577, Chrome_ChildThread] WARNING: pipe error (20): Connection reset by peer: file /mnt/temp/src/firefox/gecko-dev/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 353
[Child 5583, Chrome_ChildThread] WARNING: pipe error (16): Connection reset by peer: file /mnt/temp/src/firefox/gecko-dev/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 353
[Child 5577, Chrome_ChildThread] WARNING: pipe error (17): Connection reset by peer: file /mnt/temp/src/firefox/gecko-dev/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 353
[Child 5583, Chrome_ChildThread] WARNING: pipe error (15): Connection reset by peer: file /mnt/temp/src/firefox/gecko-dev/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 353
[Child 5577, Chrome_ChildThread] WARNING: pipe error (16): Connection reset by peer: file /mnt/temp/src/firefox/gecko-dev/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 353
[Child 5583, Chrome_ChildThread] WARNING: pipe error (3): Connection reset by peer: file /mnt/temp/src/firefox/gecko-dev/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 353
[Child 5577, Chrome_ChildThread] WARNING: pipe error (15): Connection reset by peer: file /mnt/temp/src/firefox/gecko-dev/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 353
[Child 5577, Chrome_ChildThread] WARNING: pipe error (3): Connection reset by peer: file /mnt/temp/src/firefox/gecko-dev/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 353
Illegal instruction (core dumped)

(gdb) bt
#0  0xb1407352 in mozilla::ipc::MessageChannel::OnChannelErrorFromLink() () at /mnt/temp/src/firefox/gecko-dev/objdir-wayland/dist/bin/libxul.so
#1  0xb140740c in mozilla::ipc::ProcessLink::OnChannelError() () at /mnt/temp/src/firefox/gecko-dev/objdir-wayland/dist/bin/libxul.so
#2  0xb13f69e6 in event_process_active_single_queue.isra () at /mnt/temp/src/firefox/gecko-dev/objdir-wayland/dist/bin/libxul.so
#3  0xb13f6ed2 in event_base_loop () at /mnt/temp/src/firefox/gecko-dev/objdir-wayland/dist/bin/libxul.so
#4  0xb13e648e in base::MessagePumpLibevent::Run(base::MessagePump::Delegate*) () at /mnt/temp/src/firefox/gecko-dev/objdir-wayland/dist/bin/libxul.so
#5  0xb13e7e4a in MessageLoop::Run() () at /mnt/temp/src/firefox/gecko-dev/objdir-wayland/dist/bin/libxul.so
#6  0xb13f0038 in base::Thread::ThreadMain() () at /mnt/temp/src/firefox/gecko-dev/objdir-wayland/dist/bin/libxul.so
#7  0xb13e6160 in ThreadFunc(void*) () at /mnt/temp/src/firefox/gecko-dev/objdir-wayland/dist/bin/libxul.so
#8  0xb6f05832 in start_thread () at /lib/arm-linux-gnueabihf/libpthread.so.0
#9  0xb6cd4aec in  () at /lib/arm-linux-gnueabihf/libc.so.6
Blocks: 1422709
Depends on: 1422966
Depends on: 1418792
Hi. Thanks for your work. I've compiled the Wayland branch (revision https://github.com/stransky/gecko-dev/commit/caf2a03e5e9e91635f9696e2ba0c9d522d3fc5e4) on my machine (FreeBSD 12-CURRENT, amdgpu, Mesa 17.3.0, Weston master).

It works with software rendering, with some glitches (some elements on some pages flicker, keyboard input doesn't like to refresh the screen (so like, typing in a text field doesn't show up until scrolling or resizing the window), it's hard to focus items in context menus). But also, HiDPI works (which is the primary reason I want to switch to the Wayland native version ASAP), video playback works (including the AV1 demo).

What doesn't work is EGL. In a debug build, the assertion at GLContextProviderEGL.cpp:177 (MOZ_ASSERT(aWindow)) fails. Makes sense, since the GET_NATIVE_WINDOW_… macros at the top of that file refer to X11 window IDs. In a non-debug build, "Failed to load EGL library 3". But after fixing EGL_DEFAULT_DISPLAY as suggested above by mihailescu2m, it's "Failed to create EGLSurface".
Depends on: 1425820
Depends on: 1425841
Depends on: 1425842
Depends on: 1426351
Depends on: 1426377
Depends on: 1426384
Looks like the window refresh problem is HiDPI related. It does not happen with scale=1 in Weston.
1513879786219	addons.xpi	WARN	Can't get modified time of /app/lib/firefox-59.0a1/browser/features/activity-stream@mozilla.org.xpi
1513879786222	addons.xpi	WARN	Can't get modified time of /app/lib/firefox-59.0a1/browser/features/aushelper@mozilla.org.xpi
1513879786224	addons.xpi	WARN	Can't get modified time of /app/lib/firefox-59.0a1/browser/features/firefox@getpocket.com.xpi
1513879786225	addons.xpi	WARN	Can't get modified time of /app/lib/firefox-59.0a1/browser/features/followonsearch@mozilla.com.xpi
1513879786226	addons.xpi	WARN	Can't get modified time of /app/lib/firefox-59.0a1/browser/features/formautofill@mozilla.org.xpi
1513879786227	addons.xpi	WARN	Can't get modified time of /app/lib/firefox-59.0a1/browser/features/onboarding@mozilla.org.xpi
1513879786229	addons.xpi	WARN	Can't get modified time of /app/lib/firefox-59.0a1/browser/features/presentation@mozilla.org.xpi
1513879786230	addons.xpi	WARN	Can't get modified time of /app/lib/firefox-59.0a1/browser/features/screenshots@mozilla.org.xpi
1513879786231	addons.xpi	WARN	Can't get modified time of /app/lib/firefox-59.0a1/browser/features/shield-recipe-client@mozilla.org.xpi
1513879786231	addons.xpi	WARN	Can't get modified time of /app/lib/firefox-59.0a1/browser/features/webcompat-reporter@mozilla.org.xpi
1513879786233	addons.xpi	WARN	Can't get modified time of /app/lib/firefox-59.0a1/browser/features/webcompat@mozilla.org.xpi
1513879786236	addons.xpi	WARN	Can't get modified time of /app/lib/firefox-59.0a1/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}.xpi
1513879822805	addons.xpi	WARN	Can't get modified time of /app/lib/firefox-59.0a1/browser/features/activity-stream@mozilla.org.xpi
1513879822806	addons.xpi	WARN	Can't get modified time of /app/lib/firefox-59.0a1/browser/features/aushelper@mozilla.org.xpi
1513879822806	addons.xpi	WARN	Can't get modified time of /app/lib/firefox-59.0a1/browser/features/firefox@getpocket.com.xpi
1513879822807	addons.xpi	WARN	Can't get modified time of /app/lib/firefox-59.0a1/browser/features/followonsearch@mozilla.com.xpi
1513879822807	addons.xpi	WARN	Can't get modified time of /app/lib/firefox-59.0a1/browser/features/formautofill@mozilla.org.xpi
1513879822807	addons.xpi	WARN	Can't get modified time of /app/lib/firefox-59.0a1/browser/features/onboarding@mozilla.org.xpi
1513879822808	addons.xpi	WARN	Can't get modified time of /app/lib/firefox-59.0a1/browser/features/presentation@mozilla.org.xpi
1513879822808	addons.xpi	WARN	Can't get modified time of /app/lib/firefox-59.0a1/browser/features/screenshots@mozilla.org.xpi
1513879822808	addons.xpi	WARN	Can't get modified time of /app/lib/firefox-59.0a1/browser/features/shield-recipe-client@mozilla.org.xpi
1513879822808	addons.xpi	WARN	Can't get modified time of /app/lib/firefox-59.0a1/browser/features/webcompat-reporter@mozilla.org.xpi
1513879822809	addons.xpi	WARN	Can't get modified time of /app/lib/firefox-59.0a1/browser/features/webcompat@mozilla.org.xpi
1513879822809	addons.xpi	WARN	Can't get modified time of /app/lib/firefox-59.0a1/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}.xpi
(firefox:3): Gtk-WARNING **: cannot open display: 

I thought I should report this, because the flatpak version won't run unless I have an X11-based version open first. When I don't have an X11 one open, the above is what is spat out by the terminal. I'm on Antergos running the newest GNOME shell. I don't know why this happens. It's extremely frustrating given the speed boost of wayland.

Any of you know if this should be filed in a separate bug, or is there something I can do separately to make this work? This is so weird...
(In reply to gagemorgan from comment #71)

(the extension warnings are not relevant, you didn't have to paste them all)

> (firefox:3): Gtk-WARNING **: cannot open display: 

It's not finding the display. Can you run other Wayland apps with Flatpak?
Could you give me an example of one? A quick browse through Flathub didn't really reveal which were actually Wayland and which were just XWayland.
(In reply to gagemorgan from comment #73)
> Could you give me an example of one? A quick browse through Flathub didn't
> really reveal which were actually Wayland and which were just XWayland.

I'm sure any GNOME app would be sufficient, but you can test the de facto example of Flatpak GNOME apps (GNOME Recipes): https://flathub.org/repo/appstream/org.gnome.Recipes.flatpakref
Yeah, Gedit and friends all work just fine. It's only Firefox Nightly on Wayland that has this issue, via Flatpak of course.
Any update on enabling native Wayland support by default?
Depends on: 1417892
I tried the latest NightlyWayland flatpak and although it worked almost completely, for some reason no text would appear in the address bar as I typed.  It was clearly accepting the input, because I could browse to pages, but I couldn't see what I was typing.

Is this a known issue?
(In reply to jcdawes92 from comment #77)
> for some reason no text would appear in the address bar as I
> typed.  It was clearly accepting the input, because I could browse to pages,
> but I couldn't see what I was typing.

Are you on a HiDPI display? When the compositor is at 2x scale, I see this. Text often only appears when you do some other action. Repaint/damage is broken on HiDPI :(

Also EGL doesn't work for me.
Depends on: 1429717
(In reply to greg from comment #78)
> (In reply to jcdawes92 from comment #77)
> > for some reason no text would appear in the address bar as I
> > typed.  It was clearly accepting the input, because I could browse to pages,
> > but I couldn't see what I was typing.
> 
> Are you on a HiDPI display? When the compositor is at 2x scale, I see this.
> Text often only appears when you do some other action. Repaint/damage is
> broken on HiDPI :(
> 
> Also EGL doesn't work for me.

Yes, I know that. Filed as Bug 1429717. Thanks.
Priority: P5 → P2
Depends on: 1430018
Sorry for the delay in getting back to you.  Yes, I am running HiDPI with scale 2.
Depends on: 1430725
Depends on: 1430728
Depends on: 1430775
All base patches are in tree which means the wayland port can be built/run now. (on glibc systems only due to Bug 1409707).

All you need is to build trunk with:

ac_add_options --enable-default-toolkit=cairo-gtk3-wayland
Depends on: 1431049
Depends on: 1431052
@Martin

Building it with this option means that it will run on both X and WL like all gtk apps do?
(In reply to ApB from comment #82)
> @Martin
> 
> Building it with this option means that it will run on both X and WL like
> all gtk apps do?

Yes.
(In reply to Martin Stránský [:stransky] from comment #83)
> (In reply to ApB from comment #82)
> > @Martin
> > 
> > Building it with this option means that it will run on both X and WL like
> > all gtk apps do?
> 
> Yes.

Makes sense to be made default then. At least for trunk.
Depends on: 1420555
No longer depends on: 1420555
Depends on: 1431399
Depends on: 1431337
Depends on: 1432158
Depends on: 1432414
Depends on: 1433081
Target Milestone: --- → mozilla59
"Target Milestone: --- → mozilla59"
are you considering Wayland to be stable for 59?
Flags: needinfo?(stransky)
(In reply to Sylvestre Ledru [:sylvestre] from comment #85)
> "Target Milestone: --- → mozilla59"
> are you considering Wayland to be stable for 59?

Sorry If set the flag wrongly. I mean 59 has a basic support and it's roughly functional but not good enough for general audience. I'm going to file another bug "Ship wayland builds to user" like we had for Gtk3 (Bug 1193807) and manage the stable status there.
Flags: needinfo?(stransky)
Thanks for clarification. I reset the flag. Meta bugs usually should only have a target milestone when the feature completely shipped.
Target Milestone: mozilla59 → ---
Depends on: 1434202
Depends on: 1434266
No longer blocks: 1215085
Depends on: 1215085
Depends on: 1434544
Just wanted to say thanks to everyone working to move this forward, it's really important work!  Hopefully cheerleading isn't too offtopic!
Depends on: 1434565
Depends on: 1434572
Depends on: 1434574
Depends on: 1435244
Depends on: 1435254
No longer depends on: 1433081
(In reply to Martin Stránský [:stransky] (Back on Feb 12) from comment #81)
> All base patches are in tree...

(In reply to Martin Stránský [:stransky] (Back on Feb 12) from comment #86)
> ... 59 has a basic support and it's
> roughly functional but not good enough for general audience.

Does the current Nightly ship with Wayland support enabled already? I have tried it just now, but it does not seem to work:

$ GDK_BACKEND=wayland firefox
Error: no DISPLAY environment variable specified

BTW, is there a simple way to see the build-time configuration of a firefox binary?
(In reply to pbasista from comment #89)
> BTW, is there a simple way to see the build-time configuration of a firefox
> binary?

Maybe about:buildconfig?
(In reply to Laurentiu Nicola from comment #90)
> Maybe about:buildconfig?
Thanks, I did not know about it. I was expecting some command-line way, in case the GUI is not available. Anyway...

It contains the configure options:

MOZ_AUTOMATION=1 --enable-update-channel=nightly MOZILLA_OFFICIAL=1 MOZ_PGO=1 CC=/builds/worker/workspace/build/src/gcc/bin/gcc CXX=/builds/worker/workspace/build/src/gcc/bin/g++ MOZ_STDCXX_COMPAT=1 --enable-js-shell RUSTC=/builds/worker/workspace/build/src/rustc/bin/rustc CARGO=/builds/worker/workspace/build/src/rustc/bin/cargo --with-mozilla-api-keyfile=/builds/mozilla-desktop-geoloc-api.key --with-google-api-keyfile=/builds/gapi.data LLVM_CONFIG=/builds/worker/workspace/build/src/clang/bin/llvm-config --enable-rust-simd MAKE=/usr/bin/make --enable-crashreporter --enable-verify-mar --with-branding=browser/branding/nightly

But I am not able to use that info for determining whether the Wayland support is built-in or not.
(In reply to pbasista from comment #89)
> Does the current Nightly ship with Wayland support enabled already? I have
> tried it just now, but it does not seem to work:
> 
No, it doesn't. You need to add --enable-default-toolkit=cairo-gtk3-wayland to the build options to do so.
(In reply to Jan Horak [:jhorak] from comment #92)
> (In reply to pbasista from comment #89)
> > Does the current Nightly ship with Wayland support enabled already? I have
> > tried it just now, but it does not seem to work:
> > 
> No, it doesn't. You need to add --enable-default-toolkit=cairo-gtk3-wayland
> to the build options to do so.
Ok, thanks. Do you know why it has not been enabled?

BTW, how can one, in general, verify whether a particular build-time configuration option is currently used for building the official Nightly binaries?
(In reply to pbasista from comment #93)
> Ok, thanks. Do you know why it has not been enabled?

Because there are 14 open bugs that block this one. You can see them at the top right on the Dependency list.
 
> BTW, how can one, in general, verify whether a particular build-time
> configuration option is currently used for building the official Nightly
> binaries?

about:buildconfig shows you the options.
On Plasma 5.12 on Wayland only a blank page is rendered, mouse input is not accepted and the mouse cursor is invisible.
I have just tried a custom build of Firefox Nightly on Wayland, with no additional custom configure options, and it works more or less fine in Gnome 3 on a non-hidpi display (from what I could see). In Weston, there are some strange issues:

1. Unable to click on any main menu item (Add-ons, Preferences, Customize) or buttons in the pop-up dialogs (e.g. to confirm installation of an add-on). Trying to "click" the highlighted option by pressing Enter does not seem to have any effect either.
2. Crash when switching YouTube from fullscreen back to normal mode.

There is still no opengl compositing on Linux, which is unfortunate, because of a massive positive impact it would have - i.e. a "smooth" user experience.

But the fact that Wayland part seems to be on its way to work fine is definitely great.
Yeah, about OpenGL compositing (and WebGL, and WebRender). That needs Wayland-EGL support.

Looks like the first problem is that EGL initialization is called with EGL_DEFAULT_DISPLAY instead of a wl_display. I've attempted to fix that: https://gist.github.com/myfreeweb/99f2df1a29652c0b75f2799e4b1aad38 but that's not enough. A wl_egl_window should be created to render EGL to a surface. I'm not familiar with Firefox code at all, so I couldn't make all that stuff work.
Depends on: 1438131
Depends on: 1438132
(In reply to greg from comment #97)
> Yeah, about OpenGL compositing (and WebGL, and WebRender). That needs
> Wayland-EGL support.
> 
> Looks like the first problem is that EGL initialization is called with
> EGL_DEFAULT_DISPLAY instead of a wl_display. I've attempted to fix that:
> https://gist.github.com/myfreeweb/99f2df1a29652c0b75f2799e4b1aad38 but
> that's not enough. A wl_egl_window should be created to render EGL to a
> surface. I'm not familiar with Firefox code at all, so I couldn't make all
> that stuff work.

Can you please file a new bug for it? To have it properly tracked.
Flags: needinfo?(greg)
Depends on: 1438136
No longer blocks: 1440283
Depends on: 1440283
Depends on: 1441743
Any updates on bug 1438144 and bug 1429717?
Flags: needinfo?(greg)
Depends on: 1449490
Depends on: 1444437
Depends on: 1455571
Depends on: 1456025
Depends on: 1460255
Depends on: 1460603
Depends on: 1460605
Depends on: 1460810
Depends on: 1461306
Depends on: 1462622
Depends on: 1462642
Depends on: 1464037
hm, after recent changes, my build fails with '/usr/bin/ld: error: undefined symbol: mozilla::gl::sGLXLibrary'
@greg Confirming, same issue.
Duplicate of this bug: 1464692
(In reply to greg from comment #100)
> hm, after recent changes, my build fails with '/usr/bin/ld: error: undefined
> symbol: mozilla::gl::sGLXLibrary'

That's because missing patches from Bug 1460255 - I'll post updated ones there.
Depends on: 1464808
Depends on: 1464814
Depends on: 1464823
Depends on: 1464826
Depends on: 1464994
Depends on: 1465371
Depends on: 1466386
Depends on: 1466444
Depends on: 1466473
Depends on: 1466775
Depends on: 1423598
No longer depends on: linux-egl
Depends on: 1467125
Depends on: 1467127
Depends on: 1467128
Depends on: 1467132
Depends on: 1468670
Depends on: 1468911
Depends on: 1469187
Depends on: 1470047
Depends on: 1470126
Depends on: 1471246
Hi, I'm not sure where to report it, but since a few days ago visiting maps.google.com with Firefox 60.0.2 on Linux (Debian unstable of today, Linux 4.16.16-2) under Wayland (1.15.0-2, xwayland 1.20.0-2) crashes Firefox and my whole computer with it. There's nothing in logs written to disk during this crash. I would have to setup some remote logging to have a chance to see something. This is on a laptop with an Intel video controller.
@Raphaël Hertzog Can you check if there's anything in about:crashes?

You should probably look for, or file a new issue for this.
##### begin offtopic to this thread #####

@Raphael, Hertzog, you've hit an xwayland mesa bug.  Here is the bug I filed against mozilla https://bugzilla.mozilla.org/show_bug.cgi?id=1468930, but it's not firefox's problem, they are just triggering it.

The real issue was found and is already fixed in arch and Redhat linux.
https://bugzilla.redhat.com/show_bug.cgi?id=1579067

Debian users are hitting the bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901928
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901883
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901497

To fix someone at Debian X-strikeforce has to also patch xwayland and rebuild.  Looks like that just happened:
https://salsa.debian.org/xorg-team/xserver/xorg-server/merge_requests/2
The changes have been built but have not yet been pushed into the unstable repo yet though as of when I just checked. It should be something like 1.20.0-3 when someone pushes it.

If you are antsy, or dont want to run Chrome for a couple days, or don't want to switch back to X.org without wayland for a couple days, you CAN learn how to build the debian X.org packages after applying the two needed patches using deb-src (that's what I am running the last few days, and no crashes).  It's not really that hard, like 4 terminal commands.

###### end offtopic to this thread #####
Hi, thanks to everyone who has been working on this feature.

As far as I can tell from reading the bug comments, the current state is that (preliminary) Wayland support has been merged into the source tree but is not enabled on Nightly builds. What would have to happen to enable this feature in Nightly builds? Is there a plan to do so in the near future, or is that a longer-term item?
@hdevalence I'm pretty sure it's been enabled by default in Nightly since bug 1460255 landed. I used to have 'ac_add_options --with-gl-provider=EGL' in .mozconfig, but I've commented it out a while ago and and rebuilt many times and Wayland support does work.
@greg I don't think so. The nightlies are still using Xwayland.
(In reply to hdevalence from comment #107)
> Hi, thanks to everyone who has been working on this feature.
> 
> As far as I can tell from reading the bug comments, the current state is
> that (preliminary) Wayland support has been merged into the source tree but
> is not enabled on Nightly builds. What would have to happen to enable this
> feature in Nightly builds? Is there a plan to do so in the near future, or
> is that a longer-term item?

That's a good question, IMHO there are still some outstanding issues which need to be fixed first, for instance Bug 1430775 Bug 1431399 Bug 1466295 Bug 1466444 Bug 1467132 Bug 1468911 Bug 1470047
@Martin: As long as the the normal Nightly builds are not are not providing Wayland, can we continue to use the Nightly builds from https://firefox-flatpak.mojefedora.cz/? I had the feeling my flatpak build (org.mozilla.FirefoxNightly) didn't get updated anymore, but this could be an issue on my end. From my point of view as a normal user I don't see features like WebRTC, which is still WIP in Gnome and KDE, as essential for providing Wayland with the normal builds, some limitations are expected. Thanks
(In reply to rainer from comment #111)
> @Martin: As long as the the normal Nightly builds are not are not providing
> Wayland, can we continue to use the Nightly builds from
> https://firefox-flatpak.mojefedora.cz/? I had the feeling my flatpak build
> (org.mozilla.FirefoxNightly) didn't get updated anymore, but this could be

Flatpak at https://firefox-flatpak.mojefedora.cz/ is active and should be updated, I'll check that. Also Fedora provides Wayland enabled Firefox as an option by firefox-wayland package.
Mark one more vote from me for going ahead and building nightly with Wayland support -- behind a commandline switch of course at first.  Most linux users are capable of setting and environment variable, or typing a commandline switch, but even most experienced users are going to balk at building firefox themselves because of the build environment complexity.  Jumping over to a second install via flatpack is a possible solution, but you'd get a lot more testing by letting the whole Nightly community opt in when they want to.  After all, the idea with Nightly is the ability to help with the latest features, and getting the new code every day.  I'd join the testing team then.
Not sure if this would be feasible at all, but how about a flag that can be easily set under about:config and gets checked for at startup? If I understand correctly this will be the eventual goal anyway, to check on startup whether Wayland is available or not and then accordingly start either with Xorg or Wayland backend.
Do we really need a new option that needs to be set in "about:config"? Why not rely on XDG_SESSION_TYPE and a simple logic to use a fallback if this environment variable is not set...
Not sure if I make something wrong, but my Firefox-nightly flatpak is not getting updated anymore.
$ flatpak run org.mozilla.FirefoxNightly -v
Mozilla Firefox 62.0a1
(In reply to Markus Rathgeb from comment #115)
> Do we really need a new option that needs to be set in "about:config"? Why
> not rely on XDG_SESSION_TYPE and a simple logic to use a fallback if this
> environment variable is not set...

Maybe because it's too experimental to be enabled in nightly by default?

(In reply to rainer from comment #116)
> Not sure if I make something wrong, but my Firefox-nightly flatpak is not
> getting updated anymore.
> $ flatpak run org.mozilla.FirefoxNightly -v
> Mozilla Firefox 62.0a1

See comment #112. The nightly repo hasn't seen regular builds in a while.
would love just setting XDG_SESSION_TYPE to try the pure wayland builds.
(In reply to Christian Stadelmann from comment #117)
> Maybe because it's too experimental to be enabled in nightly by default?
Yes, that was the thought process. Using XDG_SESSION_TYPE would make it the default for everyone running a Wayland session, which reasonably does not seem to be desired according to comment #110. However more people can be reached, since it is (even) simpler than installing the flatpak version.
ah, well then let's make it a commandline switch or a different variable untill the feature is stable.
As the flatpak builds are quite outdated, I would welcome if Firefox-nightly would provide Wayland support by default for testing. I don't think that there is a need for any other switch than what is used by Gtk other applications. Something like "GDK_BACKEND=wayland firefox-nightly" or "GDK_BACKEND=x11 firefox-nightly" should be enough.
I'd like to reference #1474281 as blocker, as we shouldn't turn on the wayland-backend by default before it is tackled.
Depends on: 1474281
Anyone else getting similar crashes?

#0  0xb5001282 in get_window_target_buffer () at /usr/lib/arm-linux-gnueabihf/libwayland-egl.so.1
#1  0xb4ff8cf4 in eglp_window_next_render_target () at /usr/lib/arm-linux-gnueabihf/libwayland-egl.so.1
#2  0xb4ff8f6c in eglp_first_operation_cb () at /usr/lib/arm-linux-gnueabihf/libwayland-egl.so.1
#3  0xb5019522 in gles_fbp_prepare_to_render () at /usr/lib/arm-linux-gnueabihf/libwayland-egl.so.1
#4  0xb501c3e4 in gles_fbp_clear () at /usr/lib/arm-linux-gnueabihf/libwayland-egl.so.1
#5  0xb50171a2 in gles_fb_clear () at /usr/lib/arm-linux-gnueabihf/libwayland-egl.so.1
#6  0xb12da900 in mozilla::layers::CompositorOGL::BeginFrame(mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const*, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const&, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits>*, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits>*) () at /mnt/disk1/src/firefox-62.0/debian/tmp/usr/lib/firefox/libxul.so
#7  0xb12da6f0 in mozilla::layers::CompositorOGL::BeginFrame(mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const*, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const&, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits>*, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits>*) () at /mnt/disk1/src/firefox-62.0/debian/tmp/usr/lib/firefox/libxul.so
#8  0xb1369670 in mozilla::layers::LayerManagerComposite::Render(mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&) () at /mnt/disk1/src/firefox-62.0/debian/tmp/usr/lib/firefox/libxul.so
#9  0x00000000 in  ()

firefox 62, armhf, mali T628 drivers r12p0
Depends on: 1478283
Depends on: 1480053
Depends on: 1480414
Depends on: 1481405
Depends on: 1481234
Depends on: 1482350
Depends on: 1483512
Depends on: 1484921
Depends on: 1485616
Depends on: 1485916
Depends on: 1487763
Depends on: 1489902
Depends on: 1491824
Depends on: 1492774
Depends on: 1493493
Depends on: 1496359
Depends on: 1491808
Depends on: 1497840
Depends on: 1498499
Depends on: 1500415
Depends on: 1501944
Depends on: 1503592
Anyone working on HiDPI+EGL support?
(In reply to greg from comment #126)
> Anyone working on HiDPI+EGL support?

I have investigated to a issue with windows rendering. On HIDPI screens with enabled OGL compositor firefox displays one fourth of windows/popups only. Here my simple patch, which solve the issue https://gist.github.com/IShashkin/ad33a8fd55290065fabfcf174db3ebd5 But i need help with upstreaming the patch, because i'm new in a contributing to firefox.
> I have investigated to a issue with windows rendering. On HIDPI screens with enabled OGL compositor firefox displays one fourth of windows/popups only. Here my simple patch, which solve the issue https://gist.github.com/IShashkin/ad33a8fd55290065fabfcf174db3ebd5 

Good Job!

> But i need help with upstreaming the patch, because i'm new in a contributing to firefox.

Please read this:

  https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Introduction

Probably the first thing you need to do is finding or creating a bug for this issue.
Next, attach your patch to the bug, or post it to Mozilla's Phabricator:

  https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html

Then send a review request (assign a reviewer for the patch).
Probably stransky or jhorak are suitable reviewers for this patch if you follow the precedent commits around this code.
Sure, I'm keen to review it.
Depends on: 1504689
(In reply to gashish4all from comment #127)
> I have investigated to a issue with windows rendering. On HIDPI screens with
> enabled OGL compositor firefox displays one fourth of windows/popups only.
> Here my simple patch, which solve the issue
> https://gist.github.com/IShashkin/ad33a8fd55290065fabfcf174db3ebd5 But i
> need help with upstreaming the patch, because i'm new in a contributing to
> firefox.

Thanks! Unfortunately it's still very buggy, especially with multiple monitors (one 1x scale, one 2x) and with popovers..
Depends on: 1504936
Depends on: 1504937
Depends on: 1504951
(In reply to Takuro Ashie [:ashie] from comment #128)
Thanks for the advice!

(In reply to greg from comment #130)
> Thanks! Unfortunately it's still very buggy, especially with multiple
> monitors (one 1x scale, one 2x) and with popovers..
Oh, then i'll continue a debug of the issue.
Depends on: 1505023
Depends on: 1505164
Depends on: 1505743
Depends on: 1506079
Depends on: 1506803
Depends on: 1507475
Depends on: 1507608
Depends on: 1507817
Thanks, just saw https://www.phoronix.com/scan.php?page=news_item&px=Firefox-Nightly-Ships-Wayland and updated nightly, and set  GDK_BACKEND=wayland to try it.  So far everything works great, but how do I confirm that I am running under nativ Wayland?  xeyes for instance still moves its eyes when I hover the mouse, over nightly, so I am suspicious...
So to answer my own question, Got this from here:  https://glandium.org/blog/?p=3899

"To verify whether Wayland support is enabled, go to about:support, and check “WebGL 1 Driver WSI Info” and/or “WebGL 2 Driver WSI Info”. If they say something about GLX, Wayland support is not enabled. If they say something about EGL, it is. I filed a bug to make it more obvious what is being used."
(In reply to yareckon from comment #133)
> So to answer my own question, Got this from here: 
> https://glandium.org/blog/?p=3899
> 
> "To verify whether Wayland support is enabled, go to about:support, and
> check “WebGL 1 Driver WSI Info” and/or “WebGL 2 Driver WSI Info”. If they
> say something about GLX, Wayland support is not enabled. If they say
> something about EGL, it is. I filed a bug to make it more obvious what is
> being used."

On Wayland you'll see EGL_WL_bind_wayland_display or similar Wayland extensions available at about:support.
> how do I confirm that I am running under nativ Wayland

In Gnome Shell, you can press ALT-F2, type "lg", click on "Windows", look for Firefox, click on it, then check if the first line says MetaWindowWayland (good) or MetaWindowXwayland (bad).

Under Wayland you'll also notice that wheel scrolling is smoother (pixel instead of line-based).

:stransky, is it possible that some part of Firefox makes XWayland start? I tried to run it, noticed the smoother scrolling, but didn't check what Gnome says about the window. I'm not going to use the Wayland support until it plays well with HW compositing.
(In reply to Laurentiu Nicola from comment #135)
> :stransky, is it possible that some part of Firefox makes XWayland start? I
> tried to run it, noticed the smoother scrolling, but didn't check what Gnome
> says about the window. I'm not going to use the Wayland support until it
> plays well with HW compositing.

I guess flash-plugin would need that but you may have Xwayland by default, check your DISPLAY env variable. Wayland uses WAYLAND_DISPLAY.
> I'm not going to use the Wayland support until it plays well with HW compositing.

bug 1474281 might help with that.
(In reply to yareckon from comment #132)
> Thanks, just saw
> https://www.phoronix.com/scan.php?page=news_item&px=Firefox-Nightly-Ships-
> Wayland and updated nightly, and set  GDK_BACKEND=wayland to try it.  So far
> everything works great, but how do I confirm that I am running under nativ
> Wayland?  xeyes for instance still moves its eyes when I hover the mouse,
> over nightly, so I am suspicious...

Another way to differentiate - run xwininfo. You won't be able to click on Wayland windows. The cursor will change to a crosshair over xwayland windows and you'll be able to click them in order to get their properties.
(In reply to ame from comment #138)
> Another way to differentiate - run xwininfo.

If you're in the command-line, `xlsclients` is probably simpler. Firefox shouldn't be listed.
Depends on: 1508378
Depends on: 1508594
Depends on: 1507766
Depends on: 1507764
Depends on: 1507763
Blocks: 1509152
No longer blocks: 1509152
Depends on: 1509152
Depends on: 1508357
Depends on: 1509275
Depends on: 1508803
Depends on: 1511011
Depends on: 1511951
Depends on: 1511973
Not *directly* related to Wayland (works on X11 too), but would be very very nice for Wayland users with touchpads:

https://bugzilla.mozilla.org/show_bug.cgi?id=1213601

can someone please implement the conversion from GDK scroll events to APZ events in order to get us kinetic (inertial) scrolling?
Depends on: 1213601
Depends on: 1512415
Depends on: 1512416
Depends on: 1512589
Depends on: 1513225
No longer depends on: 1513225
No longer depends on: 1514053
Could someone confirm that using nightly without a titlebar works on Wayland?? Tried on weston and the titlebar wasn't going away neither the images for the buttons were working.
(In reply to ApB from comment #141)
> Could someone confirm that using nightly without a titlebar works on
> Wayland?? Tried on weston and the titlebar wasn't going away neither the
> images for the buttons were working.

Please file that as Weston specific bug - I don't see any such issue on mutter/gnome-shell.
(In reply to Martin Stránský [:stransky] from comment #142)
> (In reply to ApB from comment #141)
> > Could someone confirm that using nightly without a titlebar works on
> > Wayland?? Tried on weston and the titlebar wasn't going away neither the
> > images for the buttons were working.
> 
> Please file that as Weston specific bug - I don't see any such issue on
> mutter/gnome-shell.

I see the same thing in Enlightenment also.
I've been using it without a titlebar for a long time, with the MOZ_GTK_TITLEBAR_DECORATION=client environment variable
(on Weston)

Maybe there's some "desktop environment detection" that enables CSD automatically without the environment variable?
(In reply to greg from comment #144)
> I've been using it without a titlebar for a long time, with the
> MOZ_GTK_TITLEBAR_DECORATION=client environment variable

Yep. Works with that both on E and Weston. No idea what mutter does differently and doesn't require an env there. But anyway shouldn't this be the default behavior on all wayland desktops since AFAIK wayland is client side only??
(In reply to ApB from comment #146)
> No idea what mutter does differently and doesn't require an env there.

Maybe Firefox specifically checks whether it's running in GNOME.

I recently reported a bug to LibreOffice — without GDK_BACKEND=wayland, it would try to detect the desktop environment, and if running without a known DE it would just go into batch server mode and not draw a GUI at all :D

> AFAIK wayland is client side only??

Wayland doesn't dictate this at all, but the general convention has been "client side by default".

KDE has introduced a negotiation protocol: https://github.com/KDE/kwayland/blob/master/src/client/protocols/server-decoration.xml (supported in KWin and Sway at least)

GTK supports it since 3.22.25: https://gitlab.gnome.org/GNOME/gtk/commit/f2adaba237519642b88ccb42b47a95cf539a2a12
(In reply to greg from comment #147)
> (In reply to ApB from comment #146)
> > No idea what mutter does differently and doesn't require an env there.
> 
> Maybe Firefox specifically checks whether it's running in GNOME.
> 

It should have the same behavior across all wayland desktops. It is a bug if it doesn't.
Depends on: 1514156
(In reply to ApB from comment #148)
> (In reply to greg from comment #147)
> > (In reply to ApB from comment #146)
> > > No idea what mutter does differently and doesn't require an env there.
> > 
> > Maybe Firefox specifically checks whether it's running in GNOME.
> > 
> 
> It should have the same behavior across all wayland desktops. It is a bug if
> it doesn't.

Filed as Bug 1514828.
Depends on: 1515402
Depends on: 1517205
Depends on: 1518427
Depends on: 1519355
Depends on: 1519940

(In reply to ApB from comment #141)

Could someone confirm that using nightly without a titlebar works on
Wayland?? Tried on weston and the titlebar wasn't going away neither the
images for the buttons were working.

yes CSD has worked in weston for a long time, not even nightly

path=GTK_THEME=Adwaita MOZ_GTK_TITLEBAR_DECORATION=client firefox

Depends on: 1522474
Depends on: 1522780
Keywords: meta
Summary: Firefox Wayland port → [meta] Firefox Wayland port
Depends on: 1523889
Depends on: 1515448
Depends on: 1525213
Depends on: 1527556
Depends on: 1527804
Depends on: 1528105
Depends on: 1528581
Depends on: 1528021
Depends on: 1527976
Depends on: 1528733
Depends on: 1529605
Depends on: 1530018
Depends on: 1530114
Depends on: 1530201
Depends on: 1531300
Depends on: 1532024
Depends on: 1532618
Depends on: 1532627
Depends on: 1532643
Depends on: 1532949
Depends on: 1532332
Depends on: 1533280
Depends on: 1534380
Depends on: 1534557
Depends on: 1534585
Depends on: 1534936
No longer blocks: 1534963
Depends on: 1534963
Depends on: 1535544
Depends on: 1535561
Depends on: 1535565
Depends on: 1535567
Depends on: 1535568
Depends on: 1535893
Depends on: 1536010
Depends on: 1536099
Depends on: 1536747
Depends on: 1521022
Depends on: 1538052
Depends on: 1500698
No longer depends on: 1500698
Depends on: 1538551
Depends on: 1530052
Depends on: 1539471
Depends on: 1466616