Open Bug 635134 (wayland) Opened 13 years ago Updated 10 days ago

[meta] Firefox Wayland port

Categories

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

All
Linux
enhancement

Tracking

()

People

(Reporter: Prescience500, Assigned: stransky)

References

(Depends on 111 open bugs, Blocks 3 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
Depends on: linux-egl
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+
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
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
Depends on: 1438144
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: 1451816
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.
(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: 1509740
Depends on: 1509931
Depends on: 1509937
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
Depends on: 1514053
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
Depends on: 1525058
Depends on: 1535230
Depends on: 1526195
Depends on: 1515467
Depends on: 1515399
Depends on: 1512925
Depends on: 1508832
Depends on: 1508675
Depends on: 1508608
Depends on: 1508582
Depends on: 1507832
Depends on: 1507756
Depends on: 1493521
Depends on: 1472576
Depends on: 1466015
Depends on: 1464606
Depends on: 1460891
Depends on: 1539773
No longer blocks: 1418611
Depends on: 1418611
Depends on: 1541003
No longer depends on: 1515402
Regressions: 1515402
No longer depends on: 1541003
Regressions: 1541003
No longer depends on: 1539773
Regressions: 1539773
Depends on: 1542808
Depends on: 1490297
Depends on: 1543035
Depends on: 1543687
No longer depends on: 1543687
Regressions: 1543687
No longer depends on: 1543035
Regressions: 1543035
Depends on: 1545927
Depends on: 1546374
Depends on: 1546669
Depends on: 1530070

Seems that there is still context menu bug under Sway/Gnome when using mixed dpi monitors, I have flicker menu on Sway and not properly scaled on Gnome on HiDPI display (also Firefox is not interpreting right side of window clicks correctly).

But yes there are no wrong positioning anymore.

(In reply to hoshiyamazaki01 from comment #151)

Seems that there is still context menu bug under Sway/Gnome when using mixed
dpi monitors, I have flicker menu on Sway and not properly scaled on Gnome
on HiDPI display (also Firefox is not interpreting right side of window
clicks correctly).

But yes there are no wrong positioning anymore.

Can you please file a new bug for it and also attach a reproduction steps? Thanks.

Flags: needinfo?(hoshiyamazaki01)
Depends on: 1548475
Depends on: 1548499
Depends on: 1548496
Depends on: 1548747
Depends on: 1548501
Depends on: 1547595
Depends on: 1549099
Depends on: 1550051
Depends on: 1550658
Regressions: 1551255
Depends on: 1551255
No longer regressions: 1551255
Depends on: wayland-sway
No longer depends on: 720523
No longer depends on: 1451816
No longer depends on: 1515399
No longer depends on: 1519940
No longer depends on: 1525058
No longer depends on: 1528581
No longer depends on: 1548501
No longer depends on: 1548747
No longer blocks: 1475802
Depends on: 1551295
Depends on: 1525058
Depends on: 1551664
Depends on: 1552020
No longer depends on: 1552020
Depends on: 1552590
Depends on: 1553747
No longer depends on: 1525058
Depends on: 1531756
Depends on: 1554677
Depends on: 1554850
Depends on: 1551092
Depends on: 1536678
Depends on: 1555308
Depends on: 1555783
Depends on: 1555812
Depends on: 1523822
Depends on: 1555866
Depends on: 1555899

Just a question:

Gnome shell works with EGL support,
Weston fails with GLXtest failed, unable to open connection to X server.
HW_COMPOSITING blocked by default: Acceleration blocked by platform.

Should wayland port work on Weston with EGL now? Is there some way to turn the EGL on? Am I missing some environment variables?
If not, will this work in future? Is there some bug that I should read and watch?
Thank You!

(In reply to michal.merta.spk from comment #153)

Weston fails with GLXtest failed, unable to open connection to X server.
HW_COMPOSITING blocked by default: Acceleration blocked by platform.

Should wayland port work on Weston with EGL now? Is there some way to turn the EGL on? Am I missing some environment variables?

Looks like you don't have Xwayland enabled in Weston's config file, and Firefox still relies on X11 for testing whether acceleration works (ugh, this should really be fixed along with any other attempts to touch X11). Try MOZ_ACCELERATED=1 or layers.acceleration.force-enabled in about:config.

(In reply to greg v [:myfreeweb] from comment #154)

Firefox still relies on X11 for testing whether acceleration works

bug 1548911 was fixed 3 days ago.

Try MOZ_ACCELERATED=1 or layers.acceleration.force-enabled in about:config.

You only need to set gfx.webrender.all to true to force-enable WebRender.

Had the gfx.webrender.all set to true, but ended with
Failed to create EGLContext
Nevermind, I don't need it to work right now :). At this moment, I'm happy, that in future it probably will work on clean Weston.

Thank both of You!

(In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #155)

bug 1548911 was fixed 3 days ago.

That's about driver detection, did it also change the GLX test?

(In reply to michal.merta.spk from comment #156)

Had the gfx.webrender.all set to true, but ended with
Failed to create EGLContext

hmmm, maybe you're running with pixman software rendering instead of a GPU? Weston on a real GPU definitely works fine with Firefox EGL

Depends on: 1556218
Depends on: 1556301

(In reply to michal.merta.spk from comment #153)

Just a question:

Gnome shell works with EGL support,
Weston fails with GLXtest failed, unable to open connection to X server.
HW_COMPOSITING blocked by default: Acceleration blocked by platform.

Should wayland port work on Weston with EGL now? Is there some way to turn
the EGL on? Am I missing some environment variables?
If not, will this work in future? Is there some bug that I should read and
watch?
Thank You!

Filed as Bug 1556301.

Depends on: 1557271
Depends on: 1557275

(In reply to greg v [:myfreeweb] from comment #157)

hmmm, maybe you're running with pixman software rendering instead of a GPU? Weston on a real GPU definitely works fine with Firefox EGL

Tried today on Fedora with latest firefox-wayland. Weston log shows that I'm using drm-backend.so, gl-renderer.so. GL vendor is Intel, EGL Wayland extension: yes.
And still getting error:

Crash Annotation GraphicsCriticalError: |[0][GFX1-]: Failed to create EGLContext

Depends on: 1558413
Depends on: 1559912
Depends on: 1560082
Depends on: 1560103
Depends on: 1560545
Depends on: 1561859
Depends on: 1561883
Depends on: 1562141
Depends on: 1562576
Depends on: 1562662
Depends on: 1562827
Depends on: 1563075
Depends on: 1564720
Depends on: 1564797
Depends on: 1565583
Depends on: 1565785
Depends on: 1553887
Depends on: 1567434
Depends on: 1567463
Depends on: 1567106
Depends on: 1567762
No longer depends on: 1565179
Depends on: 1565313
Depends on: 1569161
Depends on: 1570441
Depends on: 1572455
Depends on: 1572911
Depends on: 1575171
Depends on: 1575474
Depends on: 1576268
Depends on: 1576597
Depends on: 1577024
Depends on: 1577056
Depends on: 1577589
No longer depends on: 1577056
Depends on: 1578167

A note to GNOME Shell users who already use this: if you experienced artefacts during window animations or took window screenshots which turned out to be empty, this has just been fixed and will be part of GNOME 3.34.

See https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/692

Depends on: 1579849
Depends on: 1580169
Depends on: 1580152
Depends on: 1579823
Depends on: 1580174
Depends on: 1580595
Depends on: 1574035
Depends on: 1581480
Depends on: 1581748
Depends on: 1581773
Depends on: 1582405
Depends on: 1583035
Depends on: 1582679
Depends on: 1581851
Depends on: 1583731
Depends on: 1583732
Depends on: 1565133

Hey, I know cheerleading is a bit off topic, but wanted to log in to thank you for all the work that's happened in the last few weeks on wayland compatibility -- there has been a huge jump in usability now that the worst bugs have been bashed with window positions, drawing artifacts etc. Keep up the good work!

Depends on: 1568569
Depends on: 1584503
Depends on: 1584511
Depends on: 1584756
Depends on: 1584845
Depends on: 1585260
Depends on: 1585632
Depends on: 1585918
Depends on: 1586544
Depends on: 1587008
Depends on: 1587360
Depends on: 1587367
Depends on: 1587788
Depends on: 1587903
Depends on: 1587731
Depends on: 1588053
Depends on: 1588200
Depends on: 1588129
Depends on: 1588448
Depends on: 1588987
Depends on: 1588913
Depends on: 1589114
Depends on: 1589245
No longer depends on: 1588913
Depends on: 1589601
Depends on: 1589611
Depends on: 1589642
Depends on: 1589949
Depends on: 1590498
Depends on: 1590586
Depends on: 1589868

Hi guys,
Great job on firefox on wayland ! On Gnome 3.34, I actually loose the mouse cursor on "Activities overview".
Thanks again !

Depends on: 1590536
Depends on: 1591716
Depends on: 1592350
Depends on: 1592353
Depends on: 1592933
Depends on: 1593408
Depends on: 1438107
Depends on: 1593481
Depends on: 1593478
Depends on: 1594729
Depends on: 1598995
Depends on: 1600261
Depends on: 1600313
Depends on: 1600584
Depends on: 1600944
Depends on: 1601082
Depends on: 1602309
Depends on: 1602287
Depends on: 1603927
Depends on: 1604048
Depends on: 1586077
Depends on: 1605120
Depends on: 1605724
Depends on: 1605795
Depends on: 1605893
Depends on: 1605906
Depends on: 1604948
Depends on: 1606010
Depends on: 1605715
Depends on: 1606776
Depends on: 1606848
Depends on: 1606941
Depends on: 1607399
Depends on: 1607404
Depends on: 1605717
Depends on: 1605559
Depends on: 1607033
Depends on: 1607040
Depends on: 1607721
Depends on: 1607745
Depends on: 1608016
Depends on: 1608029
Depends on: 1608361
Depends on: 1608617
Depends on: 1607589
Depends on: 1609040
Depends on: wayland-kde
No longer depends on: 1567762
No longer depends on: 1584845
No longer depends on: 1593478
No longer depends on: 1593481
No longer depends on: 1608029
Depends on: 1609134
Depends on: 1609538
Depends on: 1592458
Depends on: 1611974
Depends on: 1608541
Depends on: 1612689
Depends on: 1612738
Depends on: 1612664
Depends on: 1614167
Depends on: 1614266
Depends on: 1615383
Depends on: 1615098
Depends on: 1616589
Depends on: 1612377
Depends on: 1617575
Depends on: 1617660
Depends on: 1617854
Depends on: 1610202
Depends on: 1618486
Depends on: 1618493
Depends on: 1618594
Depends on: 1619246
Depends on: 1619829
No longer depends on: 1619829
Depends on: 1619818
Depends on: 1619991
Depends on: 1620180
Depends on: 1620973
Depends on: 1621660
Depends on: 1621911
Depends on: 1621872
Depends on: 1620211
Depends on: wayland-pip
Depends on: 1622107
Depends on: 1618093
Depends on: 1622538
Depends on: 1622559
Depends on: 1622788
Depends on: 1622700
No longer depends on: 1622700
Depends on: 1623060
Depends on: 1620208
Depends on: 1620216
Depends on: 1623773
Depends on: 1623658
Depends on: 1624119
Depends on: 1624745
Depends on: 1624921
Depends on: 1620076
Depends on: 1625253
Depends on: 1625234
Depends on: 1625296
Depends on: 1625442
Depends on: 1625849
Depends on: 1625664
Depends on: 1626628
Depends on: 1626899
No longer depends on: 1626628
No longer depends on: 1474281
No longer depends on: 1509931
No longer depends on: 1549099
No longer depends on: 1572911
No longer depends on: 1626899
No longer depends on: 1587367
No longer depends on: 1620076
Depends on: 1627469
Depends on: 1627441
Depends on: 1627406
Depends on: 1628080
Depends on: 1628431
Depends on: 1628793
Depends on: 1629140
Depends on: 1627717
Depends on: 1629526
Depends on: 1630251
No longer depends on: 1630251
Depends on: 1603839
Depends on: 1630455
Depends on: 1629898
Depends on: 1631061
Depends on: 1631334
Depends on: 1631458
Depends on: 1631442
Depends on: 1631023
Depends on: 1611774
Depends on: 1632454
Depends on: 1632519
Depends on: 1632829
Depends on: 1373752
Depends on: 1633957
No longer depends on: 1633957
No longer depends on: 1629898
No longer depends on: 1619246
No longer depends on: 1621660
No longer depends on: 1623773
No longer depends on: 1616589
No longer depends on: 1615383
No longer depends on: 1614062
No longer depends on: 1600584
No longer depends on: 1589970
No longer depends on: 1577589
No longer depends on: 1578167
No longer depends on: 1580595
No longer depends on: 1587903
No longer depends on: 1574035
No longer depends on: 1569161
No longer depends on: 1562576
No longer depends on: 1560103
No longer depends on: 1508608
No longer depends on: 1507817
Depends on: 1634096
Depends on: 1625882
Depends on: 1634404
No longer depends on: 1575171
Depends on: 1575171
Depends on: 1634573
Depends on: 1635362
Depends on: 1635718
Depends on: 1635757
Depends on: 1567505
Depends on: 1636780
Depends on: 1636712
Depends on: 1636072
Depends on: 1635830
No longer depends on: 1490297
Depends on: 1635186
Depends on: 1638084
Depends on: 1640053
Depends on: 1640651
Depends on: 1640094
Depends on: 1641033
Depends on: 1641458
Depends on: 1641462
Depends on: 1641778
Depends on: 1641749
No longer depends on: 1641458
Depends on: 1610477
Depends on: 1618914
Depends on: 1643149
Depends on: 1643219
Depends on: 1643645
Depends on: 1643993
Depends on: 1644502
Depends on: 1640567
See Also: → 1645528
Depends on: 1645528
See Also: 1645528
Depends on: 1645600
Depends on: 1645693
Depends on: 1645695
Depends on: 1645739
No longer depends on: 1645695
Depends on: 1647072

What version will have this enabled by default?

(In reply to romulasry from comment #163)

What version will have this enabled by default?

Found the bug: 1543600

(In reply to romulasry from comment #163)

What version will have this enabled by default?

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

No longer depends on: 1634404
Depends on: 1648698
Depends on: 1646202
Depends on: 1649640
Depends on: 1647738
Depends on: 1649978
Depends on: 1653832
No longer depends on: 1653832
Depends on: 1653850
Depends on: 1654775
Depends on: 1654706
Depends on: 1651347
Depends on: 1655282
Depends on: 1655366
No longer depends on: 1655366
Depends on: 1655366
Depends on: 1656721
Depends on: 1656727
Depends on: 1656707
Depends on: 1657274
Depends on: 1656866
No longer depends on: 1655366
Depends on: 1659920
Depends on: 1660567
Blocks: 1373752
No longer depends on: 1373752
Depends on: 1662425
Depends on: 1656415
Depends on: 1663328
Depends on: 1662779
Depends on: 1667674
Depends on: 1667444
Depends on: 1667851
Depends on: 1668771
Depends on: 1668805
Depends on: 1668471
No longer depends on: 1656721
Depends on: 1670731
Depends on: 1672234
No longer depends on: 1672234
Depends on: 1672633
Depends on: 1673000
Depends on: 1673313
Depends on: 1673601
Depends on: 1673862
Depends on: 1674982
Depends on: 1675402
Depends on: 1671467
Depends on: 1677470
Depends on: 1678840
Depends on: 1677351
Depends on: 1677361
Depends on: 1645038
Depends on: 1679215
Depends on: 1679259
Depends on: 1679076
Depends on: 1679755
Depends on: 1680954
Depends on: 1680961
Depends on: 1681018
Depends on: 1580595
No longer depends on: 1680832
Depends on: 1681230
Depends on: 1683270
No longer depends on: 1683270
No longer depends on: 1680961
Depends on: 1682852
Depends on: 1685055
Depends on: 1685263
Depends on: 1684365
Depends on: 1684351
Depends on: 1685409
Depends on: 1685537
Depends on: 1685689
Depends on: 1685694
Depends on: 1686209
Depends on: 1686341
Depends on: 1643299
Depends on: 1686703
Depends on: 1687212
Depends on: 1684197
No longer depends on: 1684197
Depends on: 1687931
Depends on: 1687133
Depends on: 1688595
No longer depends on: 1688595
Depends on: 1688975
No longer depends on: 1679076
Depends on: 1681989
Depends on: 1689207
No longer depends on: 1685263
Depends on: 1538435
No longer depends on: 1538435
Depends on: 1690164
Depends on: 1690999
Depends on: 1691362
No longer depends on: 1677361
No longer depends on: egl-linux-dmabuf
No longer depends on: 1628431
Depends on: 1692451
No longer depends on: 1689207
Depends on: 1693474
Depends on: 1694038
Depends on: 1694258
Depends on: 1695227
No longer depends on: 1692451
Depends on: 1695453
Depends on: 1694928
Depends on: 1694745
No longer depends on: 1645693
No longer depends on: 1607040
No longer depends on: 1692119
Depends on: 1696050
Depends on: 1695918
Depends on: 1695656
Depends on: 1696319
Depends on: 1696876
Depends on: 1698033
Depends on: 1691662
No longer depends on: 1691662
Depends on: 1699495
No longer depends on: 1699495
Depends on: 1699942
Depends on: 1700591
Depends on: 1701182
Depends on: 1701977
No longer depends on: 1701977
Depends on: 1702606
Depends on: 1702853
Depends on: 1702854
Depends on: 1703490
Depends on: 1700005
Depends on: 1703526
Depends on: 1692119
No longer depends on: 1699942
No longer depends on: 1695656

Also https://bugzilla.mozilla.org/show_bug.cgi?id=1700340, in case it went under your radar.

Depends on: 1704290
Depends on: 1704489
Depends on: 1705048
Depends on: 1700686
Depends on: 1701845
Depends on: 1706022
Depends on: 1706624
Depends on: 1706605
Depends on: 1706452
No longer depends on: 1438107
No longer blocks: 1373752
No longer depends on: 1565313
Depends on: 1704175
No longer depends on: 1606010
Depends on: 1707124
Depends on: 1661450
Depends on: 1707209
Depends on: 1707226
No longer depends on: 1660567
No longer depends on: 1708003
No longer depends on: 1631023
Depends on: 1708276
Depends on: 1708416
No longer depends on: 1692119
No longer depends on: 1681326
No longer depends on: 1662779
No longer depends on: 1656707
No longer depends on: 1643299
No longer depends on: 1635186
No longer depends on: 1628080
Depends on: 1707833
Depends on: 1710176
Depends on: 1710197

Maybe https://bugzilla.mozilla.org/show_bug.cgi?id=1672591 should be added as a dependency? It impacts the usability of the bookmark popup when fractional scaling on wayland is enabled.

Depends on: 1710958
Depends on: 1711166
Depends on: 1711465
Depends on: 1710190
Depends on: 1712680
Depends on: 1712685
Depends on: 1712244
Depends on: 1507817
Depends on: 1713986
Depends on: 1715986
Depends on: 1716191
Depends on: 1714839
Depends on: 1716172
Depends on: 1715624
No longer depends on: 1714839
Depends on: 1716796
Depends on: 1712620
Depends on: 1716546
Depends on: 1685928
Depends on: 1713686
Depends on: 1717351
Depends on: 1717391
Depends on: 1717476
Depends on: 1718685
Depends on: 1718851
Depends on: 1713175
Depends on: 1718977
Depends on: 1719894
Depends on: 1720646
Depends on: 1720887
No longer blocks: 1712969
Depends on: 1720796
Depends on: 1720497
Depends on: 1719197
Depends on: 1720455
Depends on: 1720874
Depends on: 1721023
Depends on: 1721036
No longer depends on: 1704175
Depends on: 1721453
Depends on: 1721563
Depends on: 1721707
Depends on: 1679335
Depends on: 1722197
Depends on: 1722450
Depends on: 1722480
Depends on: 1722700
Depends on: 1723383
Depends on: 1722369
Depends on: 1723940
No longer depends on: 1723940
Depends on: 1724242
Depends on: 1725149
Depends on: 1723607
Depends on: 1722514
Depends on: 1722517
Depends on: 1726923
Depends on: 1726939
Depends on: 1725979
Depends on: 1652820
No longer depends on: 1726939
Depends on: 1727268
Depends on: 1726360
Depends on: 1704043
Depends on: 1725525
Depends on: 1728090
Depends on: 1728891
Depends on: 1717673
Depends on: 1728870
No longer depends on: 1728870
Depends on: 1728966
Depends on: 1729423
Depends on: 1729424
Depends on: 1728677
Depends on: 1729792
Depends on: 1708924
Depends on: linuxdad
Depends on: 1730476
Depends on: 1731156
Depends on: 1730114
Depends on: 1731428
Depends on: 1731489
Depends on: 1731511
No longer depends on: 1731428
Depends on: 1734566
Depends on: 1706940
Depends on: 1735377
No longer depends on: 1734819
Depends on: 1644606
Depends on: 1736209
Depends on: 1736233
Depends on: 1588950
Depends on: 1737358
Depends on: 1737715
Depends on: 1718310
Depends on: 1737443
No longer depends on: 1737443
Depends on: 1738066
Depends on: 1738299
Depends on: 1738639
Depends on: 1739137
Depends on: 1739142
Depends on: 1739339
Depends on: 1739598
Depends on: 1739600
Depends on: 1739604
Depends on: 1739622
Depends on: 1739647
Depends on: 1739783
Depends on: 1739780
Depends on: 1740124
Depends on: 1710344
Depends on: 1740255
Depends on: 1738757
Depends on: 1741575
Depends on: 1741613
No longer depends on: 1739339
Depends on: 1736268
Depends on: 1742225
Depends on: 1743385
See Also: → tbwayland
No longer depends on: 1716172
No longer depends on: 1739137
Depends on: 1737124
Depends on: 1675680
Depends on: 1744801
Depends on: 1744800
Depends on: 1744896
No longer depends on: 1737757
Depends on: 1745098
Depends on: 1745560
Depends on: 1745894
Depends on: 1745174
No longer depends on: 1742225
Depends on: 1744818
Depends on: 1746584
Depends on: 1746715
Depends on: 1737834
Depends on: 1748800
Depends on: 1747641
Depends on: 1747524
No longer depends on: 1747524
No longer depends on: 1747641

I believe #1750237 belongs here too.

Depends on: 1750563
Depends on: 849571
Depends on: 1751887
Depends on: 1751882
No longer depends on: 1751882
Depends on: 1752219
Depends on: wayland-stable
No longer blocks: wayland-nightly
Depends on: wayland-nightly
Depends on: 1665817
Depends on: 1752506
Depends on: 1751605
No longer depends on: 1751605
No longer depends on: 1751887
Depends on: 1752971
Depends on: 1752972
Depends on: 1752973
No longer depends on: 1752973
No longer depends on: 1752972
No longer depends on: 1752971
Depends on: 1755231

Depends on: 1756100

Depends on: 1756100
Depends on: 1754555
Depends on: 1756841
Depends on: 1758094
Depends on: 1760449
No longer depends on: 1752113
Depends on: 1762867
Depends on: 1763727
Depends on: 1762429
Depends on: 1764522
Depends on: 1765296
Depends on: 1766269
Depends on: 1767142
Depends on: 1767546
Depends on: 1768459
Depends on: 1768177
No longer depends on: 1768487
No longer depends on: 1769323
Depends on: 1769530
No longer depends on: 1769530
Depends on: 1769069
No longer depends on: 1769069
Depends on: 1767916
Depends on: 1769268
No longer depends on: 1768358
Depends on: 1769890
Depends on: 1771017

Redirect a needinfo that is pending on an inactive user to the triage owner.
:bhood, since the bug has high priority and recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(hoshiyamazaki01) → needinfo?(bhood)
Component: Graphics → Widget: Gtk
Flags: needinfo?(bhood)
Depends on: 1771871
No longer depends on: 1771871
Depends on: 1772164
No longer depends on: 1769890
No longer depends on: 1750563
Depends on: 1771613
No longer depends on: 1768177
Depends on: 1773844
Depends on: 1774556
Depends on: 1775002
Depends on: 1775256
Depends on: 1775266
No longer depends on: 1775002
Depends on: 1775002
Depends on: 1762443
Depends on: 1728322
Depends on: 1775325
No longer depends on: 1775002
Depends on: 1776724
Depends on: 1777393
Depends on: 1778837
Depends on: 1780190
Depends on: 1782522
Depends on: 1783829
Depends on: 1786247
Depends on: 1789558
No longer depends on: 1789558
Depends on: 1789602
No longer depends on: 1789602
Depends on: 1791129
Depends on: 1792082
Depends on: 1786219

FYI: bug 1792617 is Wayland specific.

Depends on: 1793922
No longer depends on: 1787788
Severity: normal → S3
Depends on: 1788205
No longer depends on: 1788205
Depends on: 1794577
Depends on: 1795561
No longer depends on: 1795561
Depends on: 1796724
Depends on: 1797469
Depends on: 1797978
Depends on: 1782448
Depends on: 1795860
Depends on: 1795851
Depends on: 1792676
Depends on: 1799252
Depends on: 1799575
Depends on: 1744147
Depends on: 1789602
Depends on: 1799249
No longer depends on: 1800214
Depends on: 1794266
Depends on: 1801632
Depends on: 1791779
Depends on: 1802877
Depends on: 1803203
Depends on: 1804973
Depends on: 1805208
Depends on: 1803016
Depends on: 1805776
No longer depends on: 1803016
Depends on: 1809350
Depends on: 1807660
Depends on: 1810901
Depends on: 1813084
Depends on: 1801839
No longer depends on: 1760819
Depends on: 1811574
Depends on: 1815052
Depends on: 1762687
Depends on: 1823063
No longer depends on: 1823063
Depends on: 1822764
Depends on: 1824304
Depends on: 1824287
Depends on: 1823915
Depends on: 1820758
Depends on: 1821400
Depends on: 1458474
Depends on: 1373752
Depends on: 1824552
Depends on: 1818229
No longer depends on: 1822764
Depends on: 1807809
Depends on: 1807601
Depends on: 1825053
Depends on: 1825181
Depends on: 1806279
Depends on: 1806276
No longer depends on: 1806276
Depends on: 1803511
Depends on: 1783414
No longer depends on: 1761533
Depends on: 1826583
Depends on: 1826601
No longer depends on: 1826601
Depends on: 1827429
Depends on: 1827086
Depends on: 1827446
Depends on: 1827460
No longer depends on: 1794266
Depends on: 1676705
Depends on: 1828067
Depends on: 1828070
Depends on: 1828077
Depends on: 1828255
Depends on: 1828618
Depends on: 1828772
Depends on: 1828907
Depends on: 1830215
Depends on: 1830734
Depends on: 1831051

https://bugzilla.mozilla.org/show_bug.cgi?id=1831262 belongs here.
I've been seeing about one crash a day due to it.

Depends on: 1831557
Depends on: 1832054
Depends on: 1826684
Depends on: 1831893
Depends on: 1833195
Depends on: 1834589
Depends on: 1832876
Depends on: 1836032
Depends on: 1832499
Depends on: 1836886
Depends on: 1836397
Depends on: 1791431
Depends on: 1834563
Depends on: 1840212
Depends on: 1840174
Depends on: 1841036
Depends on: 1841851
Depends on: 1832760
Depends on: 1788602
Depends on: 1841713
Depends on: 1844653
Depends on: 1844657
Depends on: 1846807
Depends on: 1745553
Depends on: 1849092
Depends on: 1849109
Depends on: 1850114
Depends on: 1850332
Depends on: 1850285
Depends on: 1850654
No longer depends on: 1850654
Depends on: 1850697
Depends on: 1850318
Depends on: 1850959
Depends on: 1849616
Depends on: 1847336
Depends on: 1854920
No longer depends on: 1831893
Depends on: 1857289
Depends on: 1855659
Depends on: 1756681
No longer depends on: 1756681
Blocks: 1863410
Depends on: 1863425
No longer depends on: 1789602
Depends on: 1863409
Depends on: 1863993
Depends on: 1865779
Depends on: 1866476
Depends on: 1866505
Depends on: 1865259
Depends on: 1866770
No longer blocks: 1787939
Depends on: 1868507
Depends on: 1869724
Depends on: 1871515
Depends on: 1744536
Depends on: 1871757
Depends on: 1872790
Depends on: 1872949
Depends on: 1873220
No longer depends on: 1873220
Depends on: 1767414
Depends on: 1873981
Depends on: 1854866
Depends on: 1874527
Depends on: 1874717
Depends on: 1874766
No longer depends on: 1871515
Depends on: 1871212
Depends on: 1874857
Depends on: 1875148
Depends on: 1871176
Depends on: 1857075
Depends on: 1877022
Depends on: 1880467
Depends on: 1878811
Depends on: 1880915
Depends on: 1881226
Depends on: 1882449
Depends on: 1882295
Depends on: 1882963
Depends on: 1882998
Depends on: 1884243
Depends on: 1884167
Depends on: 1784438
Depends on: 1875031
Depends on: 1885472
Depends on: 1885831
Depends on: 1885765
Depends on: 1886020
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: