Last Comment Bug 635134 - Make Firefox work as well with Wayland (without X) as with just X
: Make Firefox work as well with Wayland (without X) as with just X
Status: NEW
[ leave open for tracking ]
: leave-open
Product: Core
Classification: Components
Component: Graphics (show other bugs)
: Trunk
: All Linux
: P5 enhancement with 102 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
: 1190183 (view as bug list)
Depends on: gtk3 720523 726479 788319 1215104 1281425 1282015 1283055 1299083 1306613 738937 1015218
Blocks: 1215085 1228424 1305341 1215078 1215082 1215088
  Show dependency treegraph
 
Reported: 2011-02-17 18:47 PST by Michael
Modified: 2016-09-30 06:59 PDT (History)
119 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Hacks to get firefox on wayland (12.41 KB, patch)
2014-06-25 02:35 PDT, Emilio Pozuelo Monfort
no flags Details | Diff | Splinter Review
Screenshot of firefox running on weston (438.58 KB, image/png)
2014-06-25 02:36 PDT, Emilio Pozuelo Monfort
no flags Details
shaped patch (26.91 KB, patch)
2015-02-19 04:50 PST, Martin Stránský
karlt: feedback+
Details | Diff | Splinter Review
wayland v.2 (26.20 KB, patch)
2015-03-04 06:28 PST, Martin Stránský
karlt: review+
Details | Diff | Splinter Review
wayland for check-in (26.17 KB, patch)
2015-03-05 03:56 PST, Martin Stránský
no flags Details | Diff | Splinter Review
WIP patch (21.47 KB, patch)
2015-08-05 07:22 PDT, Martin Stránský
karlt: feedback+
Details | Diff | Splinter Review
patch (11.73 KB, patch)
2016-06-20 07:31 PDT, Martin Stránský
no flags Details | Diff | Splinter Review

Description Michael 2011-02-17 18:47:32 PST
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.
Comment 1 George Carstoiu 2011-03-14 05:34:56 PDT
I think what you are proposing is a really good idea that would make FF even more popular between FOSS users.
Comment 2 Michael 2011-09-13 19:45:53 PDT
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.
Comment 3 Darxus 2012-03-13 13:34:51 PDT
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 4 antistress 2012-03-15 06:44:29 PDT
Note that a live CD allows to test applications on Wayland http://phoronix.com/forums/showthread.php?69394-Wayland-s-Weston-Lands-In-Ubuntu-12-04-LTS&p=254064#post254064
Comment 5 Darxus 2012-04-05 09:30:03 PDT
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 Darxus 2012-04-05 09:31:29 PDT
Similar work on gnome-terminal: https://bugzilla.gnome.org/show_bug.cgi?id=673323
Comment 7 Robert Kaiser 2012-04-05 10:10:26 PDT
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 Darxus 2012-04-05 10:28:11 PDT
"#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 Darxus 2012-04-05 10:29:00 PDT
Robert: Outputting directly via GL sounds lovely, where can I find more info on that effort?  Is there a bug open?
Comment 10 Robert Kaiser 2012-04-05 10:38:14 PDT
(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.)
Comment 11 Benoit Jacob [:bjacob] (mostly away) 2012-04-09 10:32:58 PDT
The ongoing work to stop using X pixmaps directly is an important prerequisite for this. Marking as blockers.
Comment 12 Franck Arnaud 2013-10-27 07:08:44 PDT
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!).
Comment 13 Emilio Pozuelo Monfort 2014-06-25 02:35:29 PDT
Created attachment 8445763 [details] [diff] [review]
Hacks to get firefox on wayland

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.
Comment 14 Emilio Pozuelo Monfort 2014-06-25 02:36:51 PDT
Created attachment 8445765 [details]
Screenshot of firefox running on weston

This is a screenshot of firefox running on weston.

Also see http://emilio.pozuelo.org/?p=75
Comment 15 Benoit Jacob [:bjacob] (mostly away) 2014-06-25 04:02:42 PDT
\o/ cheers for that!
Comment 16 Martin Stránský 2015-02-03 06:11:29 PST
Downstream bug - https://bugzilla.redhat.com/show_bug.cgi?id=1054334
Comment 17 Martin Stránský 2015-02-19 04:50:31 PST
Created attachment 8566469 [details] [diff] [review]
shaped patch

Karl, can you please check this one? It uses gtkx.h wrapper to provide a GDK_IS_X11_DISPLAY() macro for GTK2 builds.
Comment 18 Karl Tomlinson (:karlt) 2015-03-01 19:36:14 PST
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.
Comment 19 Martin Stránský 2015-03-04 06:28:13 PST
Created attachment 8572611 [details] [diff] [review]
wayland v.2

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.
Comment 20 Karl Tomlinson (:karlt) 2015-03-04 16:05:39 PST
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?
Comment 21 Martin Stránský 2015-03-05 03:56:57 PST
Created attachment 8573204 [details] [diff] [review]
wayland for check-in

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.
Comment 22 Karl Tomlinson (:karlt) 2015-03-05 14:19:20 PST
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.
Comment 24 Ryan VanderMeulen [:RyanVM] 2015-03-07 10:14:09 PST
https://hg.mozilla.org/mozilla-central/rev/53503035a93d
Comment 25 Martin Stránský 2015-08-05 07:22:15 PDT
Created attachment 8643709 [details] [diff] [review]
WIP patch

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!
Comment 26 Florian Bender 2015-08-10 13:21:56 PDT
Just FYI, switching over to GTK+3 seems to be coming soon, see e.g. Bug 1186748.
Comment 27 Florian Bender 2015-08-10 14:00:41 PDT
Sorry, Bug 1186003 is the one. We have GTK+3 in Fx 42+.
Comment 28 Jeff Muizelaar [:jrmuizel] 2015-08-24 19:19:06 PDT
(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 29 Karl Tomlinson (:karlt) 2015-09-06 23:38:38 PDT
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.
Comment 30 Kevin Brosnan [:kbrosnan] 2015-10-06 17:33:20 PDT
*** Bug 1190183 has been marked as a duplicate of this bug. ***
Comment 31 Martin Stránský 2016-06-20 07:17:14 PDT
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.
Comment 32 Martin Stránský 2016-06-20 07:31:59 PDT
Created attachment 8763594 [details] [diff] [review]
patch

Complete Wayland patch for latest trunk.
Comment 33 Goku 2016-06-23 08:25:29 PDT
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 Jonas Heinrich 2016-06-23 13:19:26 PDT
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
Comment 35 Martin Stránský 2016-06-23 22:50:42 PDT
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.
Comment 36 Goku 2016-06-24 05:35:41 PDT
>>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 Goku 2016-06-25 07:40:15 PDT
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.
Comment 38 vsechto 2016-07-08 23:47:06 PDT
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 Hussam Al-Tayeb 2016-08-05 14:17:55 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.