Bug 635134 (wayland)

[meta] Firefox Wayland port

NEW
Assigned to

Status

()

P2
enhancement
8 years ago
a day ago

People

(Reporter: Prescience500, Assigned: stransky)

Tracking

(Depends on: 49 bugs, Blocks: 4 bugs, {feature, leave-open, meta})

Trunk
All
Linux
feature, leave-open, meta
Points:
---
720523, 726479, 1213601, 1418792, 1423598, 1451816, 1466444, 1467127, 1471246, 1474281, 1478283, 1481405, 1492774, 1493493, 1496359, 1507817, 1508378, 1508594, 1508803, 1509740, 1509931, 1509937, 1515402, 1515448, 1517205, 1519940, 1521022, 1523889, 1527976, 1528581, 1528733, 1529605, 1530018, 1530114, 1530201, 1532618, 1532627, 1532643, 1533280, 1534936, 1535544, 1535561, 1535565, 1535568, 1535893, 1536010, 1536747, 1538052, 1538551, gtk3, 738937, 1015218, 1215085, 1215104, 1281425, 1282015, 1283055, 1299083, 1306613, 1336047, 1336048, 1336071, 1337369, 1339916, 1339917, 1339920, 1345666, 1348310, 1348990, 1383156, 1396101, 1409707, 1409716, 1416186, 1417892, 1422966, 1425820, 1425841, 1425842, 1426351, 1426377, 1426384, 1429717, 1430018, 1430725, 1430728, 1430775, 1431049, 1431052, 1431337, 1431399, 1432158, 1432414, 1434202, 1434266, 1434544, 1434565, 1434572, 1434574, 1435244, 1435254, 1438131, 1438132, 1438136, 1438144, 1440283, 1441743, 1444437, 1449490, 1455571, 1456025, 1460255, 1460603, 1460605, 1460810, 1461306, 1462622, 1462642, 1464037, 1464808, 1464814, 1464823, 1464826, 1464994, 1465371, 1466295, 1466386, 1466473, 1466775, 1467125, 1467128, 1467132, 1468670, 1468911, 1469187, 1470047, 1470126, 1480053, 1480414, 1481234, 1482350, 1483512, 1484921, 1485616, 1485916, 1487763, 1489902, 1491808, 1491824, 1497840, 1498499, 1500415, 1501944, 1503592, 1504689, 1504936, 1504937, 1504951, 1505023, 1505164, 1505743, 1506079, 1506803, 1507475, 1507608, 1507763, 1507764, 1507766, 1508041, 1508082, 1508357, 1509152, 1509275, 1511011, 1511951, 1511973, 1512415, 1512416, 1512589, 1514156, 1518427, 1519355, 1522474, 1522780, 1525213, 1527556, 1527804, 1528021, 1528105, 1531300, 1532024, 1532332, 1532949, 1534380, 1534557, 1534585, 1534963, 1535567, 1536099
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [ leave open for tracking ], URL)

Attachments

(2 attachments, 5 obsolete attachments)

(Reporter)

Description

8 years ago
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

Comment 1

8 years ago
I think what you are proposing is a really good idea that would make FF even more popular between FOSS users.
(Reporter)

Comment 2

8 years ago
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

Updated

7 years ago
Depends on: 627699
Component: Widget → Graphics
QA Contact: general → thebes

Comment 3

7 years ago
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.

Comment 5

7 years ago
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.

Comment 6

7 years ago
Similar work on gnome-terminal: https://bugzilla.gnome.org/show_bug.cgi?id=673323

Comment 7

7 years ago
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.

Comment 8

7 years ago
"#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.

Comment 9

7 years ago
Robert: Outputting directly via GL sounds lovely, where can I find more info on that effort?  Is there a bug open?

Comment 10

7 years ago
(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: 788319

Comment 12

6 years ago
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!).
(Assignee)

Updated

5 years ago
Depends on: 943407
(Assignee)

Updated

5 years ago
No longer depends on: 943407
Depends on: 1015218
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!

Updated

5 years ago
Depends on: 1034064

Updated

5 years ago
No longer depends on: 1034064
(Assignee)

Comment 17

4 years ago
Posted 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+
(Assignee)

Comment 19

4 years ago
Posted 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+
(Assignee)

Comment 21

4 years ago
Posted 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
(Assignee)

Updated

4 years ago
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
(Assignee)

Updated

4 years ago
Keywords: checkin-needed
(Assignee)

Comment 25

4 years ago
Posted 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)

Comment 26

4 years ago
Just FYI, switching over to GTK+3 seems to be coming soon, see e.g. Bug 1186748.

Comment 27

4 years ago
Sorry, Bug 1186003 is the one. We have GTK+3 in Fx 42+.
(In reply to Martin Stránský from comment #25)
> - disables OMTC (is it supposed to work somehow on wayland?)

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

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

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

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

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

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

I don't know anything about that.

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

> - disables GXL support

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

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

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

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

> - try to detect propper backend from ENV variables

I haven't looked into details there either but that is also an isolated change.
Attachment #8643709 - Flags: feedback?(karlt) → feedback+
Duplicate of this bug: 1190183
(Assignee)

Updated

4 years ago
Blocks: 1215078
(Assignee)

Updated

4 years ago
Blocks: 1215082
(Assignee)

Updated

4 years ago
Blocks: 1215085
(Assignee)

Updated

4 years ago
Blocks: 1215088
(Assignee)

Updated

4 years ago
Blocks: 1215104
Blocks: 1228424
(Assignee)

Comment 31

3 years ago
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.
(Assignee)

Comment 32

3 years ago
Posted patch patchSplinter Review
Complete Wayland patch for latest trunk.
Attachment #8573204 - Attachment is obsolete: true
Attachment #8643709 - Attachment is obsolete: true
(Assignee)

Updated

3 years ago
Depends on: 1281425

Comment 33

3 years ago
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.

Comment 34

3 years ago
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
(Assignee)

Comment 35

3 years ago
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.
(Assignee)

Updated

3 years ago
Depends on: 1282015

Comment 36

3 years ago
>>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

Comment 37

3 years ago
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.
(Assignee)

Updated

3 years ago
Depends on: 1283055
No longer blocks: 1215104
Depends on: 1215104
Depends on: 726479

Comment 38

3 years ago
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'

Comment 39

3 years ago
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.
(Assignee)

Updated

3 years ago
Depends on: 1299083
Blocks: 1305341
(Assignee)

Updated

3 years ago
Depends on: 1306613
Comment hidden (spam)
Comment hidden (advocacy)
Comment hidden (advocacy)
Comment hidden (advocacy)

Comment 45

2 years ago
@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!

Comment 46

2 years ago
Further ...
> % file CTypes.o                                                                :(
> CTypes.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped

Comment 47

2 years ago
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
Comment hidden (advocacy)
Comment hidden (offtopic)
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).
Comment hidden (advocacy)
(Assignee)

Updated

2 years ago
Summary: Make Firefox work as well with Wayland (without X) as with just X → Firefox Wayland port
(Assignee)

Updated

2 years ago
Depends on: 1336047
(Assignee)

Updated

2 years ago
Depends on: 1336048
(Assignee)

Updated

2 years ago
Depends on: 1336071
(Assignee)

Updated

2 years ago
Depends on: 1337369
Duplicate of this bug: 1332857

Comment 53

2 years ago
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
(Assignee)

Updated

2 years ago
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
(Assignee)

Comment 55

2 years ago
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.

Comment 56

2 years ago
(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.
(Assignee)

Comment 57

2 years ago
(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.

Comment 58

2 years ago
(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

Comment 60

2 years ago
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 !

Comment 61

2 years ago
(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.
(Assignee)

Comment 62

2 years ago
(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!

Comment 63

2 years ago
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?

Updated

2 years ago
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.

Updated

2 years ago
Depends on: 1396101
(Assignee)

Updated

a year ago
Depends on: 1409707
(Assignee)

Updated

a year ago
Depends on: 1409716

Comment 65

a year ago
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
(Assignee)

Comment 66

a year ago
(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?

Comment 67

a year ago
(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
(Assignee)

Updated

a year ago
Alias: wayland
(Assignee)

Updated

a year ago
Assignee: nobody → stransky
(Assignee)

Updated

a year ago
Depends on: 1416186

Comment 68

a year ago
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
(Assignee)

Updated

a year ago
Depends on: 1422966

Comment 69

a year ago
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".
(Assignee)

Updated

a year ago
Depends on: 1425820
(Assignee)

Updated

a year ago
Depends on: 1425841
(Assignee)

Updated

a year ago
Depends on: 1425842
(Assignee)

Updated

a year ago
Depends on: 1426351
(Assignee)

Updated

a year ago
Depends on: 1426377
(Assignee)

Updated

a year ago
Depends on: 1426384

Comment 70

a year ago
Looks like the window refresh problem is HiDPI related. It does not happen with scale=1 in Weston.

Comment 71

a year ago
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...

Comment 72

a year ago
(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?

Comment 73

a year ago
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.

Comment 74

a year ago
(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

Comment 75

a year ago
Yeah, Gedit and friends all work just fine. It's only Firefox Nightly on Wayland that has this issue, via Flatpak of course.

Comment 76

a year ago
Any update on enabling native Wayland support by default?
(Assignee)

Updated

a year ago
Depends on: 1417892

Comment 77

a year ago
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?

Comment 78

a year ago
(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.
(Assignee)

Updated

a year ago
Depends on: 1429717
(Assignee)

Comment 79

a year ago
(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.
(Assignee)

Updated

a year ago
Priority: P5 → P2
(Assignee)

Updated

a year ago
Depends on: 1430018

Comment 80

a year ago
Sorry for the delay in getting back to you.  Yes, I am running HiDPI with scale 2.
(Assignee)

Updated

a year ago
Depends on: 1430725
(Assignee)

Updated

a year ago
Depends on: 1430728
Depends on: 1430775
(Assignee)

Comment 81

a year ago
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
(Assignee)

Updated

a year ago
Depends on: 1431049
(Assignee)

Updated

a year ago
Depends on: 1431052

Comment 82

a year ago
@Martin

Building it with this option means that it will run on both X and WL like all gtk apps do?
(Assignee)

Comment 83

a year ago
(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.

Comment 84

a year ago
(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
(Assignee)

Updated

a year ago
No longer depends on: 1420555
(Assignee)

Updated

a year ago
Depends on: 1431399
(Assignee)

Updated

a year ago
Depends on: 1431337
(Assignee)

Updated

a year ago
Depends on: 1432158
(Assignee)

Updated

a year ago
Depends on: 1432414
(Assignee)

Updated

a year ago
Depends on: 1433081
(Assignee)

Updated

a year ago
Target Milestone: --- → mozilla59
"Target Milestone: --- → mozilla59"
are you considering Wayland to be stable for 59?
Flags: needinfo?(stransky)
(Assignee)

Comment 86

a year ago
(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 → ---
(Assignee)

Updated

a year ago
Depends on: 1434202
(Assignee)

Updated

a year ago
Depends on: 1434266
(Assignee)

Updated

a year ago
No longer blocks: 1215085
Depends on: 1215085
(Assignee)

Updated

a year ago
Depends on: 1434544

Comment 88

a year ago
Just wanted to say thanks to everyone working to move this forward, it's really important work!  Hopefully cheerleading isn't too offtopic!
(Assignee)

Updated

a year ago
Depends on: 1434565
(Assignee)

Updated

a year ago
Depends on: 1434572
(Assignee)

Updated

a year ago
Depends on: 1434574
(Assignee)

Updated

a year ago
Depends on: 1435244
(Assignee)

Updated

a year ago
Depends on: 1435254
(Assignee)

Updated

a year ago
No longer depends on: 1433081

Comment 89

a year ago
(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?

Comment 91

a year ago
(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.

Comment 93

a year ago
(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.

Comment 95

a year ago
On Plasma 5.12 on Wayland only a blank page is rendered, mouse input is not accepted and the mouse cursor is invisible.

Comment 96

a year ago
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.

Comment 97

a year ago
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.
(Assignee)

Updated

a year ago
Depends on: 1438131
(Assignee)

Updated

a year ago
Depends on: 1438132
(Assignee)

Comment 98

a year ago
(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)
(Assignee)

Updated

a year ago
Depends on: 1438136

Updated

a year ago
Depends on: 1438144
(Assignee)

Updated

a year ago
Blocks: 1440283
(Assignee)

Updated

a year ago
No longer blocks: 1440283
Depends on: 1440283
Depends on: 1441743

Comment 99

a year ago
Any updates on bug 1438144 and bug 1429717?
Flags: needinfo?(greg)
(Assignee)

Updated

a year ago
Depends on: 1449490
(Assignee)

Updated

a year ago
Depends on: 1444437

Updated

a year ago
Depends on: 1451816
Depends on: 1455571
Depends on: 1456025
(Assignee)

Updated

11 months ago
Depends on: 1460255
(Assignee)

Updated

11 months ago
Depends on: 1460603
(Assignee)

Updated

11 months ago
Depends on: 1460605
(Assignee)

Updated

11 months ago
Depends on: 1460810
(Assignee)

Updated

11 months ago
Depends on: 1461306
(Assignee)

Updated

10 months ago
Depends on: 1462622
(Assignee)

Updated

10 months ago
Depends on: 1462642
(Assignee)

Updated

10 months ago
Depends on: 1464037

Comment 100

10 months ago
hm, after recent changes, my build fails with '/usr/bin/ld: error: undefined symbol: mozilla::gl::sGLXLibrary'

Comment 101

10 months ago
@greg Confirming, same issue.

Updated

10 months ago
Duplicate of this bug: 1464692
(Assignee)

Comment 103

10 months ago
(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.

Updated

10 months ago
Depends on: 1464808

Updated

10 months ago
Depends on: 1464814

Updated

10 months ago
Depends on: 1464823

Updated

10 months ago
Depends on: 1464826
Depends on: 1464994
(Assignee)

Updated

10 months ago
Depends on: 1465371

Updated

10 months ago
Depends on: 1466386

Updated

10 months ago
Depends on: 1466444
(Assignee)

Updated

10 months ago
Depends on: 1466473
(Assignee)

Updated

10 months ago
Depends on: 1466775
(Assignee)

Updated

10 months ago
Depends on: 1423598
(Assignee)

Updated

10 months ago
No longer depends on: 788319
(Assignee)

Updated

10 months ago
Depends on: 1467125
(Assignee)

Updated

10 months ago
Depends on: 1467127
(Assignee)

Updated

10 months ago
Depends on: 1467128
(Assignee)

Updated

10 months ago
Depends on: 1467132
Depends on: 1466295

Updated

10 months ago
Depends on: 1468670
(Assignee)

Updated

9 months ago
Depends on: 1468911

Updated

9 months ago
Depends on: 1469187
Depends on: 1470047
(Assignee)

Updated

9 months ago
Depends on: 1470126
(Assignee)

Updated

9 months ago
Depends on: 1471246

Comment 104

9 months ago
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.

Comment 105

9 months ago
@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.

Comment 106

9 months ago
##### 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 #####

Comment 107

9 months ago
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?

Comment 108

9 months ago
@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.

Comment 109

9 months ago
@greg I don't think so. The nightlies are still using Xwayland.
(Assignee)

Comment 110

9 months ago
(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

Comment 111

9 months ago
@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
(Assignee)

Comment 112

9 months ago
(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.

Comment 113

9 months ago
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.

Comment 114

9 months ago
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.

Comment 115

9 months ago
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...

Comment 116

9 months ago
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.

Comment 118

9 months ago
would love just setting XDG_SESSION_TYPE to try the pure wayland builds.

Comment 119

9 months ago
(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.

Comment 120

9 months ago
ah, well then let's make it a commandline switch or a different variable untill the feature is stable.

Comment 121

9 months ago
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.

Comment 122

9 months ago
I'd like to reference #1474281 as blocker, as we shouldn't turn on the wayland-backend by default before it is tackled.
(Assignee)

Updated

9 months ago
Depends on: 1474281

Comment 123

8 months ago
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
Comment hidden (advocacy)
Comment hidden (advocacy)
(Assignee)

Updated

8 months ago
Blocks: 1475802
(Assignee)

Updated

8 months ago
Depends on: 1478283

Updated

8 months ago
Depends on: 1480053
(Assignee)

Updated

8 months ago
Depends on: 1480414
(Assignee)

Updated

8 months ago
Depends on: 1481405
(Assignee)

Updated

8 months ago
Depends on: 1481234
(Assignee)

Updated

8 months ago
Depends on: 1482350
(Assignee)

Updated

7 months ago
Depends on: 1483512
(Assignee)

Updated

7 months ago
Depends on: 1484921
(Assignee)

Updated

7 months ago
Depends on: 1485616
(Assignee)

Updated

7 months ago
Depends on: 1485916
(Assignee)

Updated

7 months ago
Depends on: 1487763
(Assignee)

Updated

6 months ago
Depends on: 1491824
Depends on: 1492774
(Assignee)

Updated

6 months ago
Depends on: 1496359
(Assignee)

Updated

6 months ago
Depends on: 1491808
(Assignee)

Updated

6 months ago
Depends on: 1497840
(Assignee)

Updated

6 months ago
Depends on: 1498499

Updated

5 months ago
Depends on: 1500415
(Assignee)

Updated

5 months ago
Depends on: 1501944
(Assignee)

Updated

5 months ago
Depends on: 1503592

Comment 126

5 months ago
Anyone working on HiDPI+EGL support?

Comment 127

5 months ago
(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.
(Assignee)

Comment 129

5 months ago
Sure, I'm keen to review it.
(Assignee)

Updated

5 months ago
Depends on: 1504689

Comment 130

5 months ago
(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..
(Assignee)

Updated

5 months ago
Depends on: 1504936
(Assignee)

Updated

5 months ago
Depends on: 1504937
(Assignee)

Updated

5 months ago
Depends on: 1504951

Comment 131

5 months ago
(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.
(Assignee)

Updated

5 months ago
Depends on: 1505023
(Assignee)

Updated

5 months ago
Depends on: 1505164
(Assignee)

Updated

5 months ago
Depends on: 1505743
(Assignee)

Updated

5 months ago
Depends on: 1506079
(Assignee)

Updated

4 months ago
Depends on: 1506803
(Assignee)

Updated

4 months ago
Depends on: 1507475
(Assignee)

Updated

4 months ago
Depends on: 1507608

Updated

4 months ago
Depends on: 1507817

Comment 132

4 months ago
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...

Comment 133

4 months ago
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."
(Assignee)

Comment 134

4 months ago
(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.

Comment 135

4 months ago
> 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.
(Assignee)

Comment 136

4 months ago
(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.

Comment 137

4 months ago
> I'm not going to use the Wayland support until it plays well with HW compositing.

bug 1474281 might help with that.

Comment 138

4 months ago
(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.

Comment 139

4 months ago
(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.

Updated

4 months ago
Depends on: 1508378

Updated

4 months ago
Depends on: 1508594

Updated

4 months ago
Depends on: 1507766

Updated

4 months ago
Depends on: 1507764

Updated

4 months ago
Depends on: 1507763
Depends on: 1508082
Depends on: 1508041

Updated

4 months ago
Blocks: 1509152

Updated

4 months ago
No longer blocks: 1509152
Depends on: 1509152

Updated

4 months ago
Depends on: 1508357
Depends on: 1509275

Updated

4 months ago
Depends on: 1509740

Updated

4 months ago
Depends on: 1509931

Updated

4 months ago
Depends on: 1509937
Depends on: 1508803
(Assignee)

Updated

4 months ago
Depends on: 1511011
(Assignee)

Updated

4 months ago
Depends on: 1511951
(Assignee)

Updated

4 months ago
Depends on: 1511973

Comment 140

4 months ago
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?
(Assignee)

Updated

4 months ago
Depends on: 1213601
(Assignee)

Updated

4 months ago
Depends on: 1512415
(Assignee)

Updated

4 months ago
Depends on: 1512416
(Assignee)

Updated

4 months ago
Depends on: 1512589
(Assignee)

Updated

3 months ago
No longer depends on: 1513225

Updated

3 months ago
Depends on: 1514053

Updated

3 months ago
No longer depends on: 1514053

Comment 141

3 months ago
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.
(Assignee)

Comment 142

3 months ago
(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.

Comment 143

3 months ago
(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.

Comment 144

3 months ago
I've been using it without a titlebar for a long time, with the MOZ_GTK_TITLEBAR_DECORATION=client environment variable

Comment 145

3 months ago
(on Weston)

Maybe there's some "desktop environment detection" that enables CSD automatically without the environment variable?

Comment 146

3 months ago
(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??

Comment 147

3 months ago
(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

Comment 148

3 months ago
(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.
(Assignee)

Updated

3 months ago
Depends on: 1514156
(Assignee)

Updated

3 months ago
Blocks: 1514828
(Assignee)

Comment 149

3 months ago
(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

Updated

3 months ago
Depends on: 1517205

Updated

3 months ago
Depends on: 1518427
(Assignee)

Updated

2 months ago
Depends on: 1519355

Updated

2 months ago
Depends on: 1519940

Comment 150

2 months ago

(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

(Assignee)

Updated

2 months ago
Depends on: 1522474
(Assignee)

Updated

2 months ago
Depends on: 1522780
Keywords: meta
Summary: Firefox Wayland port → [meta] Firefox Wayland port
Keywords: feature
(Assignee)

Updated

2 months ago
Depends on: 1523889
(Assignee)

Updated

2 months ago
Depends on: 1515448
Depends on: 1525213
Depends on: 1527556
Depends on: 1527804

Updated

a month ago
Depends on: 1528105

Updated

a month ago
Depends on: 1528581
Depends on: 1528021
(Assignee)

Updated

a month ago
Depends on: 1527976

Updated

a month ago
Depends on: 1528733
(Assignee)

Updated

a month ago
Depends on: 1529605
Depends on: 1530018
Depends on: 1530114

Updated

25 days ago
Depends on: 1531300
Depends on: 1532024
Depends on: 1532618
Depends on: 1532627
(Assignee)

Updated

20 days ago
Depends on: 1532643
Depends on: 1532949
(Assignee)

Updated

19 days ago
Depends on: 1532332
(Assignee)

Updated

19 days ago
Depends on: 1533280
(Assignee)

Updated

14 days ago
Depends on: 1534380
Depends on: 1534557
Depends on: 1534585

Updated

12 days ago
Depends on: 1534936
(Assignee)

Updated

12 days ago
Blocks: 1534963
(Assignee)

Updated

11 days ago
No longer blocks: 1534963
Depends on: 1534963
(Assignee)

Updated

11 days ago
Depends on: 1535544

Updated

11 days ago
Depends on: 1535561

Updated

11 days ago
Depends on: 1535565
(Assignee)

Updated

10 days ago
Depends on: 1535567

Updated

10 days ago
Depends on: 1535568
Depends on: 1535893

Updated

8 days ago
Depends on: 1536010
(Assignee)

Updated

7 days ago
Depends on: 1536099

Updated

6 days ago
Depends on: 1536747
(Assignee)

Updated

5 days ago
Depends on: 1521022
Depends on: 1538052

Updated

2 days ago
Depends on: 1500698

Updated

2 days ago
No longer depends on: 1500698
You need to log in before you can comment on or make changes to this bug.