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

[meta] Firefox Wayland port

Categories

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

All
Linux
enhancement

Tracking

()

People

(Reporter: Prescience500, Assigned: stransky)

References

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

Details

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

Attachments

(2 files, 5 obsolete files)

User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b12pre) Gecko/20110217 Firefox/4.0b12pre Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b12pre) Gecko/20110217 Firefox/4.0b12pre Currently, Linux, as well as other FOSS operating systems, uses X. A replacement for X is currently being developed called Wayland. It would be nice if when Wayland comes out, Firefox would be ready and support Wayland without needing X. Reproducible: Always Wayland won't be ready for widespread use for some time. As I understand it (which may be slightly inaccurate), even after it is ready for widespread use, it'll still be used to talk to X in order to speed things up. It'll probably be even longer before Linux desktops are able to ditch X altogether.
Component: General → Widget
Product: Firefox → Core
QA Contact: general → general
Version: unspecified → Trunk
I think what you are proposing is a really good idea that would make FF even more popular between FOSS users.
It seems that Google is working on porting Chrome to Wayland according to Phoronix. http://www.phoronix.com/scan.php?page=news_item&px=OTc4NA Mozilla will probably have to port it's products at some point in order to stay competitive on Linux.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Depends on: gtk3
Component: Widget → Graphics
QA Contact: general → thebes
It looks like firefox uses GTK, which should make this easier. GTK 3.4 supports wayland 0.85. The page with instructions to build GTK with wayland support also has a "Porting your GTK+ application" section: http://wayland.freedesktop.org/gtk.html I guess I'll just paste the whole thing here: The GTK+ port to Wayland has some major functionality gaps. Porting of applications at this stage should simply be to start identifying where applications makes API calls that will not function under Wayland. * Ensure that your application uses gtk+-3.0 for its pkg-config request. * Your application must not use any API in the gdk_x11_ namespace or any raw Xlib calls. * Check the errata below for issues that might affect your application. API to access the underlying wl_surface, wl_shell_surface and wl_display may be available in later versions of the code but are not available right now.
Other gtk applications are handling this by wrapping xlib calls in "#ifdef GDK_WINDOWING_X11". I'm curious how much of the gecko gtk3 work could be handled this easily, and how much would require something more involved.
Mozilla stuff is not a "gtk application", we only use GTK for a few specific things like getting the theming of our XUL widgets right. Our work to remove direct usages of X Bitmaps and go for GL for everything is way more relevant to potentially running on Wayland than any GTK stuff is.
"#ifdef GDK_WINDOWING_X11" is only a build time check, so it's insufficient. A run time check is also needed, something like "if (GDK_IS_X11_DISPLAY (display))", documented here: http://developer.gnome.org/gtk3/3.3/ch24s02.html#id1502079 There are also GDK_IS_X11_SCREEN and GDK_IS_X11_WINDOW.
Robert: Outputting directly via GL sounds lovely, where can I find more info on that effort? Is there a bug open?
(In reply to Darxus from comment #9) > Robert: Outputting directly via GL sounds lovely, where can I find more info > on that effort? Is there a bug open? AFAIK there are multiple bug open for that, probably blocking some "enable OpenGL layers by default" bug, just search for OpenGL stuff here in Bugzilla and you should find a few. (Note that I'm no code, just an interested community member, so I don't know all the details, but I usually have some rough grasp of the overview.)
The ongoing work to stop using X pixmaps directly is an important prerequisite for this. Marking as blockers.
Depends on: 720523, 738937
Depends on: linux-egl
What about starting from Mobile Firefox? On a tablet it's pretty much like a desktop browser (indeed without some of the bloat of classic desktop Firefox), and porting from Android should be simpler than disentangling the X/GTK mess (I bet Android Firefox doesn't use xpixmaps for example!).
No longer depends on: 943407
Depends on: 1015218
Attached patch Hacks to get firefox on wayland (obsolete) — Splinter Review
I recently looked at this. I tried to get Firefox-gtk3 running on Weston, using hacks wherever needed to avoid X11 calls / paths. After those bunch of hacks (which obviously would need to be done properly), I managed to get Firefox running on Weston, not without issues. More work is needed to turn those hacks into proper checks, to add suitable codepaths for wayland where necessary, and to fix regressions / bugs. The attached patch is what I used, which as I said is quite hacky. This was tested on top of r186206. Perhaps various / most of those tests aren't necessary if MOZ_X11 is forced to 0 in configure.ac, I didn't try that. In any case, support for both X11 and Wayland in the same binary would be desirable, with runtime detection checks to pick one path or the other.
This is a screenshot of firefox running on weston. Also see http://emilio.pozuelo.org/?p=75
\o/ cheers for that!
Depends on: 1034064
No longer depends on: 1034064
Attached patch shaped patch (obsolete) — Splinter Review
Karl, can you please check this one? It uses gtkx.h wrapper to provide a GDK_IS_X11_DISPLAY() macro for GTK2 builds.
Attachment #8445763 - Attachment is obsolete: true
Attachment #8566469 - Flags: feedback?(karlt)
Comment on attachment 8566469 [details] [diff] [review] shaped patch >+#include <gtk/gtkx.h> > > #include "gfxImageSurface.h" > #ifdef MOZ_X11 > #include <gdk/gdkx.h> GDK_IS_X11_DISPLAY should be provided by <gdk/gdkx.h>, so <gtk/gtkx.h> should be unnecessary, here at least. >+++ b/widget/gtk/compat/gtk/gtkx.h >@@ -0,0 +1,14 @@ >+/* This Source Code Form is subject to the terms of the Mozilla Public >+ * License, v. 2.0. If a copy of the MPL was not distributed with this >+ * file, You can obtain one at http://mozilla.org/MPL/2.0/. */ >+ >+#ifndef GTKX_WRAPPER_H >+#define GTKX_WRAPPER_H >+ >+#if (MOZ_WIDGET_GTK == 3) >+#include_next <gtk/gtkx.h> >+#endif >+ >+#define GDK_IS_X11_DISPLAY(a) (true) widget/gtk/compat/gdk/gdkx.h would be the place to define GDK_IS_X11_DISPLAY. It should only be defined if not already defined, or only #if (GTK_MAJOR_VERSION == 2). >+ bool useXlibSurface = (UseXRender() && !UseImageOffscreenSurfaces()); >+ if (useXlibSurface) { >+ useXlibSurface = GDK_IS_X11_DISPLAY(gdk_display_get_default()); >+ } Assume that UseXRender() returning true means the default display is an X11 display. >+ mGdkDisplay = gdk_display_open(display_name); >+ if (!mGdkDisplay) { >+ PR_fprintf(PR_STDERR, "Error: cannot open display: %s\n", display_name); >+ return 1; >+ } >+ gdk_display_manager_set_default_display (gdk_display_manager_get(), >+ mGdkDisplay); > #endif /* MOZ_WIDGET_GTK */ > > #ifdef MOZ_ENABLE_XREMOTE > // handle --remote now that xpcom is fired up > bool newInstance; > { > char *e = PR_GetEnv("MOZ_NO_REMOTE"); > mDisableRemote = (e && *e); >+#if defined(MOZ_WIDGET_GTK) >+ if (!GDK_IS_X11_DISPLAY(mGdkDisplay)) >+ mDisableRemote = true; XInitThreads() needs to be called before Xlib is used. I wonder whether it would be tidier to set mDisableRemote in the MOZ_WIDGET_GTK block above and then use mDisableRemote = mDisableRemove && e && *e; > gdk_window_add_filter(mRootWindow, root_window_event_filter, this); > #ifdef MOZ_X11 >- mNetWorkareaAtom = >- XInternAtom(GDK_WINDOW_XDISPLAY(mRootWindow), "_NET_WORKAREA", False); >+ if (GDK_IS_X11_DISPLAY(gdk_display_get_default())) >+ mNetWorkareaAtom = >+ XInternAtom(GDK_WINDOW_XDISPLAY(mRootWindow), "_NET_WORKAREA", False); > #endif I don't know whether Wayland uses properties like _NET_WORKAREA or whether it has its own mechanisms. If it uses this property then GDK has gdk_atom_intern_static_string() for any backend. If Wayland uses another mechanism, then initialize mNetWorkareaAtom to something so that it won't match in root_window_event_filter. > if (synthEvent) { > #ifdef MOZ_X11 >- event.refPoint.x = nscoord(xevent.xmotion.x); >- event.refPoint.y = nscoord(xevent.xmotion.y); >- >- modifierState = xevent.xmotion.state; >- >- event.time = xevent.xmotion.time; >-#else >- event.refPoint.x = nscoord(aEvent->x); >- event.refPoint.y = nscoord(aEvent->y); >- >- modifierState = aEvent->state; >- >- event.time = aEvent->time; >+ if (isX11Display) { >+ event.refPoint.x = nscoord(xevent.xmotion.x); >+ event.refPoint.y = nscoord(xevent.xmotion.y); >+ >+ modifierState = xevent.xmotion.state; >+ >+ event.time = xevent.xmotion.time; >+ } >+ else { >+#endif /* MOZ_X11 */ >+ event.refPoint.x = nscoord(aEvent->x); >+ event.refPoint.y = nscoord(aEvent->y); >+ >+ modifierState = aEvent->state; >+ >+ event.time = aEvent->time; >+#ifdef MOZ_X11 >+ } > #endif /* MOZ_X11 */ synthEvent can only be true when MOZ_X11 is defined and GDK_IS_X11_DISPLAY(gdk_display_get_default()), so most of this is not needed.
Attachment #8566469 - Flags: feedback?(karlt) → feedback+
Attached patch wayland v.2 (obsolete) — Splinter Review
Thanks, there's an updated one. Another check added tp nsWindow::HasPendingInputEvent() which was missing in the original patch. > XInitThreads() needs to be called before Xlib is used. > > I wonder whether it would be tidier to set mDisableRemote in the > MOZ_WIDGET_GTK block above and then use > mDisableRemote = mDisableRemove && e && *e; I see. I think the correct construction is (mDisableRemove || (e && *e)). > If Wayland uses another mechanism, then initialize mNetWorkareaAtom to > something so that it won't match in root_window_event_filter. It does not use _NET_WORKAREA so I initialized it to 0 in class constructor.
Attachment #8566469 - Attachment is obsolete: true
Attachment #8572611 - Flags: review?(karlt)
Comment on attachment 8572611 [details] [diff] [review] wayland v.2 (In reply to Martin Stránský from comment #19) > I see. I think the correct construction is (mDisableRemove || (e && *e)). Ah, yes. Thank you. >+ if (!GDK_IS_X11_DISPLAY(mGdkDisplay)) >+ mDisableRemote = true; >+# endif Please add {} on this conditional block, which is the style we're moving towards (though I don't mind missing {} around jump statements such as return). And please remove the space in "# endif" so that it aligns with the #if above. >+STUB(gdk_cairo_create) I don't see this used outside nptest_gtk2.cpp, where the stub should not be necessary. Please remove, or is a preprocessing change causing something to depend on this?
Attachment #8572611 - Flags: review?(karlt) → review+
Attached patch wayland for check-in (obsolete) — Splinter Review
Thanks, there's the one for check-in. try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=04dd5d53450f gdk_cairo_create is a leftover from my experiments with nsWindow::GetThebesSurface() which need an update but I'd prefer to leave it to another patch.
Attachment #8572611 - Attachment is obsolete: true
Whiteboard: [ leave open for more patches ]
Whiteboard: [ leave open for more patches ] → [ leave open for tracking ]
Please file new bugs, blocking this one, for other patches. A single Bugzilla bug is not good at managing multiple threads, but multiple bugs can organize related information.
Keywords: leave-open
Attached patch WIP patch (obsolete) — Splinter Review
There's a followup patch for non X11 bacekends (tested on broadway and wayland). I'd like to discuss it here and we can divide it to separate bugs then. It address those issues: - draw to container window - we can't draw on toplevel window on wayland because it's bigger than the widget and it's used to render widget shadow. So I use mozcontainer window for rendering. - create gfxSurface (in GetThebesSurface) as a wrapped one. Is there any better way? Off screen surface or something different? - cairo subsurfaces fixes - non-X11 gtk uses cairo subsurface types which are tricky - reported as images but image backend mostly fails. - disables GXL support - disables OMTC (is it supposed to work somehow on wayland?) - try to detect propper backend from ENV variables Thanks!
Attachment #8643709 - Flags: feedback?(karlt)
Just FYI, switching over to GTK+3 seems to be coming soon, see e.g. Bug 1186748.
Sorry, Bug 1186003 is the one. We have GTK+3 in Fx 42+.
(In reply to Martin Stránský from comment #25) > - disables OMTC (is it supposed to work somehow on wayland?) What's broken with OMTC? Disabling it isn't going to be an option.
Comment on attachment 8643709 [details] [diff] [review] WIP patch (In reply to Martin Stránský from comment #25) > - draw to container window - we can't draw on toplevel window on wayland > because it's bigger than the widget and it's used to render widget shadow. > So I use mozcontainer window for rendering. This makes sense. It is more a CSD issue than a Wayland issue. The issue exists on X11 also (bug 1195002). I assume Wayland doesn't force compositors to depend on clients for decorations. > - create gfxSurface (in GetThebesSurface) as a wrapped one. That seems reasonable to me. I'm not familiar with the drawing model though. Is a swap-buffers required after drawing? > - cairo subsurfaces fixes - non-X11 gtk uses cairo subsurface types which > are tricky - reported as images but image backend mostly fails. I don't know anything about that. These things are going to be easier to review in conceptual chunks with reasoning behind them. If this is working around a cairo bug, then we need to consider why this can't be fixed in cairo. I suspect we have time before the Wayland port is ready for production. > - disables GXL support Haven't really looked at that, but that can be handled separately, I assume. > - disables OMTC (is it supposed to work somehow on wayland?) Currently GetThebesSurface() is used on the compositor thread which is an existing bug because GDK is not designed for multi-thread access. For OMTC, I guess it is possible to fetch the surface on the main thread and then return it when requested on the compositor thread. > - try to detect propper backend from ENV variables I haven't looked into details there either but that is also an isolated change.
Attachment #8643709 - Flags: feedback?(karlt) → feedback+
I tested latest nightly and works fine on Wayland, with patches from Bug 1215085 Bug 1215088 and Bug 1215104. So we need just 3 extra patches to make Firefox work on Wayland.
Attached patch patchSplinter Review
Complete Wayland patch for latest trunk.
Attachment #8573204 - Attachment is obsolete: true
Attachment #8643709 - Attachment is obsolete: true
Archlinux 64bit. With the above patch Firefox is still broken on Wayland+Weston. E.g content in Firefox window is updated only after focusing on another window and focusing back to the Firefox window. Off Main Thread Compositing is disabled.
I created a package which applies the patches to the 47.0 sources: https://aur.archlinux.org/packages/firefox-wayland Unfortunately this doesn't work yet ... I guess I have apply this patch to trunk? I started firefox with: GDK_BACKEND=wayland firefox
Working packages are here but that's Fedora builds (wayland by default, EGL enabled): https://copr.fedorainfracloud.org/coprs/stransky/firefox-wayland The missing rendering content is caused by enabled OMTC, you need to set: layers.offmainthreadcomposition.force-disabled:true on trunk.
>>Working packages are here but that's Fedora builds (wayland by default, EGL enabled): Tried these as well, same issue. >>The missing rendering content is caused by enabled OMTC, you need to set: OMTC is disabled, also content is not missing but is drawn only on window blur. For example, content is updated after focusing on another window and focusing back to the Firefox window. Also, clicking in the addressbar does not show the cursor, but clicking on the menu and bookmarks icon does show menus. mozconfig . $topsrcdir/browser/config/mozconfig ac_add_options --enable-default-toolkit=cairo-gtk3 ac_add_options --with-system-nspr ac_add_options --with-system-nss ac_add_options --enable-system-sqlite ac_add_options --disable-system-cairo ac_add_options --enable-system-ffi ac_add_options --disable-debug ac_add_options --enable-optimize="-g -O2" ac_add_options --disable-crashreporter ac_add_options --disable-tests ac_add_options --without-system-jpeg ac_add_options --with-system-libvpx ac_add_options --with-system-icu ac_add_options --enable-release ac_add_options --enable-pie ac_add_options --with-gl-provider=EGL export BUILD_OFFICIAL=1 export MOZILLA_OFFICIAL=1 export MOZILLA_TELEMETRY=0 mk_add_options BUILD_OFFICIAL=1 mk_add_options MOZILLA_OFFICIAL=1
The nightly on Wayland should now work on Archlinux after these steps. - gfx/thebes/gfxPlatform.cpp - find LayersOffMainThreadCompositionForceDisabled( and add return false; to the top of the function. Setting layers.offmainthreadcomposition.force-disabled instead did not work for me. - Uncheck "Enable multi-process Nightly" in the preferences and restart. Otherwise, not configuration pages will be empty. - When clicking some icons or items in the menu - e.g Zoom In, you have to hold Ctrl.
No longer blocks: 1215104
Depends on: 1215104
all y bags when i start firefox-trunk without xwayland (firefox-trunk:3588): Gtk-WARNING **: Failed to parse /home/x/.config/gtk-3.0/se ttings.ini: Key file does not start with a group (firefox-trunk:3588): Gtk-WARNING **: Failed to parse/home/x/.config/gtk-3.0/se ttings.ini: Key file does not start with a group (firefox-trunk:3588): GConf-WARNING **: Client failed to connect to the D-BUS da emon: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11 (firefox-trunk:3588): GConf-WARNING **: Client failed to connect to the D-BUS da emon: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11 Ñибка ÑегменÑиÑÐ¾Ð²Ð°Ð½Ð¸Ñ [Child 4679] ###!!! ABORT: Aborting on channel error.: file /build/firefox-tru nk-_hskEs/firefox-trunk-50.0~a1~hg20160708r304097/ipc/glue/MessageChannel.cpp, l ine 2053 (firefox-trunk:4805): Gtk-WARNING **: Failed to parse /home/x/.config/gtk-3.0/se ttings.ini: Key file does not have group 'Settings'
This isn't directly related to this bug in particular but I have tried running a regular firefox build in a wayland session using Xwayland. Resizing the window causes the black box window to be drawn behind firefox. It disappears when resizing is done. Can that be fixed? This alone would be a huge usability improvement.
Blocks: gem
@Martin Stránský: Thank you for maintaining this repo! I tried to make a buildscript for the ArchLinux user repository here: https://aur.archlinux.org/packages/firefox-wayland-git Unfortunately I get a compile error, maybe you know why: > /usr/bin/g++ -std=gnu++11 -o Unified_cpp_js_src9.o -c -I/home/onny/projects/firefox-wayland-git/src/gecko-dev/obj-x86_64-pc-linux-gnu/dist/system_wrappers -include /home/onny/projects/firefox-wayland-git/src/gecko-dev/config/gcc_hidden.h -DNDEBUG=1 -DTRIMMED=1 -DENABLE_BINARYDATA -DENABLE_SIMD -DENABLE_SHARED_ARRAY_BUFFER -DEXPORT_JS_API -DJS_HAS_CTYPES '-DDLL_PREFIX="lib"' '-DDLL_SUFFIX=".so"' -I/home/onny/projects/firefox-wayland-git/src/gecko-dev/js/src -I/home/onny/projects/firefox-wayland-git/src/gecko-dev/obj-x86_64-pc-linux-gnu/js/src -I/home/onny/projects/firefox-wayland-git/src/gecko-dev/obj-x86_64-pc-linux-gnu/dist/include -I/usr/include/nspr -fPIC -DMOZILLA_CLIENT -include /home/onny/projects/firefox-wayland-git/src/gecko-dev/obj-x86_64-pc-linux-gnu/js/src/js-confdefs.h -MD -MP -MF .deps/Unified_cpp_js_src9.o.pp -D_FORTIFY_SOURCE=2 -O2 -Wall -Wc++11-compat -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings -Wno-invalid-offsetof -Wc++14-compat -Wno-error=maybe-uninitialized -Wno-error=deprecated-declarations -Wno-error=array-bounds -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4 -fno-delete-null-pointer-checks -fno-schedule-insns2 -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -pthread -pipe -g -freorder-blocks -O3 -fomit-frame-pointer -I/usr/lib/libffi-3.2.1/include -Wno-shadow -Werror=format /home/onny/projects/firefox-wayland-git/src/gecko-dev/obj-x86_64-pc-linux-gnu/js/src/Unified_cpp_js_src9.cpp > libjs_static.a > rm -f libjs_static.a libjs_static.a.desc > /home/onny/projects/firefox-wayland-git/src/gecko-dev/obj-x86_64-pc-linux-gnu/_virtualenv/bin/python /home/onny/projects/firefox-wayland-git/src/gecko-dev/config/expandlibs_exec.py --extract -- ar crs libjs_static.a RegExp.o CTypes.o Library.o Parser.o StoreBuffer.o ExecutableAllocatorPosix.o Disassembler-x86-shared.o jsarray.o jsatom.o jsdtoa.o jsmath.o jsutil.o pm_linux.o ConditionVariable.o MutexImpl.o Thread.o Initialization.o TraceLogging.o TraceLoggingGraph.o TraceLoggingTypes.o Unified_cpp_js_src0.o Unified_cpp_js_src1.o Unified_cpp_js_src10.o Unified_cpp_js_src11.o Unified_cpp_js_src12.o Unified_cpp_js_src13.o Unified_cpp_js_src14.o Unified_cpp_js_src15.o Unified_cpp_js_src16.o Unified_cpp_js_src17.o Unified_cpp_js_src18.o Unified_cpp_js_src19.o Unified_cpp_js_src2.o Unified_cpp_js_src20.o Unified_cpp_js_src21.o Unified_cpp_js_src22.o Unified_cpp_js_src23.o Unified_cpp_js_src24.o Unified_cpp_js_src25.o Unified_cpp_js_src26.o Unified_cpp_js_src27.o Unified_cpp_js_src28.o Unified_cpp_js_src29.o Unified_cpp_js_src3.o Unified_cpp_js_src30.o Unified_cpp_js_src31.o Unified_cpp_js_src32.o Unified_cpp_js_src33.o Unified_cpp_js_src34.o Unified_cpp_js_src35.o Unified_cpp_js_src36.o Unified_cpp_js_src37.o Unified_cpp_js_src38.o Unified_cpp_js_src39.o Unified_cpp_js_src4.o Unified_cpp_js_src40.o Unified_cpp_js_src5.o Unified_cpp_js_src6.o Unified_cpp_js_src7.o Unified_cpp_js_src8.o Unified_cpp_js_src9.o ../../config/external/ffi/libconfig_external_ffi.a ../../config/external/icu/libicu.a ../../config/external/fdlibm/libfdlibm.a ../../config/external/nspr/libnspr.a ../../config/external/zlib/libzlib.a > make[3]: *** [/home/onny/projects/firefox-wayland-git/src/gecko-dev/config/recurse.mk:33: compile] Error 2 > make[3]: Leaving directory '/home/onny/projects/firefox-wayland-git/src/gecko-dev/obj-x86_64-pc-linux-gnu' > make[2]: *** [/home/onny/projects/firefox-wayland-git/src/gecko-dev/config/rules.mk:523: default] Error 2 > make[2]: Leaving directory '/home/onny/projects/firefox-wayland-git/src/gecko-dev/obj-x86_64-pc-linux-gnu' > make[1]: *** [/home/onny/projects/firefox-wayland-git/src/gecko-dev/client.mk:415: realbuild] Error 2 > make[1]: Leaving directory '/home/onny/projects/firefox-wayland-git/src/gecko-dev' > make: *** [client.mk:170: build] Error 2 > ==> ERROR: A failure occurred in build(). > Aborting... It looks like this command is failing: > Executing: ar crs CTypes.o ConditionVariable.o Disassembler-x86-shared.o ExecutableAllocatorPosix.o Initialization.o Library.o MutexImpl.o Parser.o RegExp.o StoreBuffer.o Thread.o TraceLogging.o TraceLoggingGraph.o TraceLoggingTypes.o Unified_cpp_js_src0.o Unified_cpp_js_src1.o Unified_cpp_js_src10.o Unified_cpp_js_src11.o Unified_cpp_js_src12.o Unified_cpp_js_src13.o Unified_cpp_js_src14.o Unified_cpp_js_src15.o Unified_cpp_js_src16.o Unified_cpp_js_src17.o Unified_cpp_js_src18.o Unified_cpp_js_src19.o Unified_cpp_js_src2.o Unified_cpp_js_src20.o Unified_cpp_js_src21.o Unified_cpp_js_src22.o Unified_cpp_js_src23.o Unified_cpp_js_src24.o Unified_cpp_js_src25.o Unified_cpp_js_src26.o Unified_cpp_js_src27.o Unified_cpp_js_src28.o Unified_cpp_js_src29.o Unified_cpp_js_src3.o Unified_cpp_js_src30.o Unified_cpp_js_src31.o Unified_cpp_js_src32.o Unified_cpp_js_src33.o Unified_cpp_js_src34.o Unified_cpp_js_src35.o Unified_cpp_js_src36.o Unified_cpp_js_src37.o Unified_cpp_js_src38.o Unified_cpp_js_src39.o Unified_cpp_js_src4.o Unified_cpp_js_src40.o Unified_cpp_js_src5.o Unified_cpp_js_src6.o Unified_cpp_js_src7.o Unified_cpp_js_src8.o Unified_cpp_js_src9.o jsarray.o jsatom.o jsdtoa.o jsmath.o jsutil.o pm_linux.o tmpj6OdrR/e_acos.o tmpj6OdrR/e_acosh.o tmpj6OdrR/e_asin.o tmpj6OdrR/e_atan2.o tmpj6OdrR/e_atanh.o tmpj6OdrR/e_cosh.o tmpj6OdrR/e_exp.o tmpj6OdrR/e_hypot.o tmpj6OdrR/e_log.o tmpj6OdrR/e_log10.o tmpj6OdrR/e_log2.o tmpj6OdrR/e_pow.o tmpj6OdrR/e_sinh.o tmpj6OdrR/e_sqrt.o tmpj6OdrR/k_exp.o tmpj6OdrR/s_asinh.o tmpj6OdrR/s_atan.o tmpj6OdrR/s_cbrt.o tmpj6OdrR/s_ceil.o tmpj6OdrR/s_ceilf.o tmpj6OdrR/s_copysign.o tmpj6OdrR/s_expm1.o tmpj6OdrR/s_fabs.o tmpj6OdrR/s_floor.o tmpj6OdrR/s_floorf.o tmpj6OdrR/s_log1p.o tmpj6OdrR/s_nearbyint.o tmpj6OdrR/s_rint.o tmpj6OdrR/s_rintf.o tmpj6OdrR/s_scalbn.o tmpj6OdrR/s_tanh.o tmpj6OdrR/s_trunc.o tmpj6OdrR/s_truncf.o RegExp.o CTypes.o Library.o Parser.o StoreBuffer.o ExecutableAllocatorPosix.o Disassembler-x86-shared.o jsarray.o jsatom.o jsdtoa.o jsmath.o jsutil.o pm_linux.o ConditionVariable.o MutexImpl.o Thread.o Initialization.o TraceLogging.o TraceLoggingGraph.o TraceLoggingTypes.o Unified_cpp_js_src0.o Unified_cpp_js_src1.o Unified_cpp_js_src10.o Unified_cpp_js_src11.o Unified_cpp_js_src12.o Unified_cpp_js_src13.o Unified_cpp_js_src14.o Unified_cpp_js_src15.o Unified_cpp_js_src16.o Unified_cpp_js_src17.o Unified_cpp_js_src18.o Unified_cpp_js_src19.o Unified_cpp_js_src2.o Unified_cpp_js_src20.o Unified_cpp_js_src21.o Unified_cpp_js_src22.o Unified_cpp_js_src23.o Unified_cpp_js_src24.o Unified_cpp_js_src25.o Unified_cpp_js_src26.o Unified_cpp_js_src27.o Unified_cpp_js_src28.o Unified_cpp_js_src29.o Unified_cpp_js_src3.o Unified_cpp_js_src30.o Unified_cpp_js_src31.o Unified_cpp_js_src32.o Unified_cpp_js_src33.o Unified_cpp_js_src34.o Unified_cpp_js_src35.o Unified_cpp_js_src36.o Unified_cpp_js_src37.o Unified_cpp_js_src38.o Unified_cpp_js_src39.o Unified_cpp_js_src4.o Unified_cpp_js_src40.o Unified_cpp_js_src5.o Unified_cpp_js_src6.o Unified_cpp_js_src7.o Unified_cpp_js_src8.o Unified_cpp_js_src9.o ../../modules/fdlibm/src/e_acos.o ../../modules/fdlibm/src/e_acosh.o ../../modules/fdlibm/src/e_asin.o ../../modules/fdlibm/src/e_atan2.o ../../modules/fdlibm/src/e_atanh.o ../../modules/fdlibm/src/e_cosh.o ../../modules/fdlibm/src/e_exp.o ../../modules/fdlibm/src/e_hypot.o ../../modules/fdlibm/src/e_log.o ../../modules/fdlibm/src/e_log10.o ../../modules/fdlibm/src/e_log2.o ../../modules/fdlibm/src/e_pow.o ../../modules/fdlibm/src/e_sinh.o ../../modules/fdlibm/src/e_sqrt.o ../../modules/fdlibm/src/k_exp.o ../../modules/fdlibm/src/s_asinh.o ../../modules/fdlibm/src/s_atan.o ../../modules/fdlibm/src/s_cbrt.o ../../modules/fdlibm/src/s_ceil.o ../../modules/fdlibm/src/s_ceilf.o ../../modules/fdlibm/src/s_copysign.o ../../modules/fdlibm/src/s_expm1.o ../../modules/fdlibm/src/s_fabs.o ../../modules/fdlibm/src/s_floor.o ../../modules/fdlibm/src/s_floorf.o ../../modules/fdlibm/src/s_log1p.o ../../modules/fdlibm/src/s_nearbyint.o ../../modules/fdlibm/src/s_rint.o ../../modules/fdlibm/src/s_rintf.o ../../modules/fdlibm/src/s_scalbn.o ../../modules/fdlibm/src/s_tanh.o ../../modules/fdlibm/src/s_trunc.o ../../modules/fdlibm/src/s_truncf.o > ar: CTypes.o: File format not recognized I would really appreciate any hint :) Thanks!
Further ... > % file CTypes.o :( > CTypes.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
Following files doesn't seem to exists: > ../../config/external/ffi/libconfig_external_ffi.a ../../config/external/icu/libicu.a ../../config/external/fdlibm/libfdlibm.a ../../config/external/nspr/libnspr.a ../../config/external/zlib/libzlib.a So this command works fine > ar crs libjs_static.a RegExp.o CTypes.o Library.o Parser.o StoreBuffer.o ExecutableAllocatorPosix.o Disassembler-x86-shared.o jsarray.o jsatom.o jsdtoa.o jsmath.o jsutil.o pm_linux.o ConditionVariable.o MutexImpl.o Thread.o Initialization.o TraceLogging.o TraceLoggingGraph.o TraceLoggingTypes.o Unified_cpp_js_src0.o Unified_cpp_js_src1.o Unified_cpp_js_src10.o Unified_cpp_js_src11.o Unified_cpp_js_src12.o Unified_cpp_js_src13.o Unified_cpp_js_src14.o Unified_cpp_js_src15.o Unified_cpp_js_src16.o Unified_cpp_js_src17.o Unified_cpp_js_src18.o Unified_cpp_js_src19.o Unified_cpp_js_src2.o Unified_cpp_js_src20.o Unified_cpp_js_src21.o Unified_cpp_js_src22.o Unified_cpp_js_src23.o Unified_cpp_js_src24.o Unified_cpp_js_src25.o Unified_cpp_js_src26.o Unified_cpp_js_src27.o Unified_cpp_js_src28.o Unified_cpp_js_src29.o Unified_cpp_js_src3.o Unified_cpp_js_src30.o Unified_cpp_js_src31.o Unified_cpp_js_src32.o Unified_cpp_js_src33.o Unified_cpp_js_src34.o Unified_cpp_js_src35.o Unified_cpp_js_src36.o Unified_cpp_js_src37.o Unified_cpp_js_src38.o Unified_cpp_js_src39.o Unified_cpp_js_src4.o Unified_cpp_js_src40.o Unified_cpp_js_src5.o Unified_cpp_js_src6.o Unified_cpp_js_src7.o Unified_cpp_js_src8.o Unified_cpp_js_src9.o Where as this command, from the build script, fails > % /home/onny/projects/firefox-wayland-git/src/gecko-dev/obj-x86_64-pc-linux-gnu/_virtualenv/bin/python /home/onny/projects/firefox-wayland-git/src/gecko-dev/config/expandlibs_exec.py --extract -- ar crs libjs_static.a RegExp.o CTypes.o Library.o Parser.o StoreBuffer.o ExecutableAllocatorPosix.o Disassembler-x86-shared.o jsarray.o jsatom.o jsdtoa.o jsmath.o jsutil.o pm_linux.o ConditionVariable.o MutexImpl.o Thread.o Initialization.o TraceLogging.o TraceLoggingGraph.o TraceLoggingTypes.o Unified_cpp_js_src0.o Unified_cpp_js_src1.o Unified_cpp_js_src10.o Unified_cpp_js_src11.o Unified_cpp_js_src12.o Unified_cpp_js_src13.o Unified_cpp_js_src14.o Unified_cpp_js_src15.o Unified_cpp_js_src16.o Unified_cpp_js_src17.o Unified_cpp_js_src18.o Unified_cpp_js_src19.o Unified_cpp_js_src2.o Unified_cpp_js_src20.o Unified_cpp_js_src21.o Unified_cpp_js_src22.o Unified_cpp_js_src23.o Unified_cpp_js_src24.o Unified_cpp_js_src25.o Unified_cpp_js_src26.o Unified_cpp_js_src27.o Unified_cpp_js_src28.o Unified_cpp_js_src29.o Unified_cpp_js_src3.o Unified_cpp_js_src30.o Unified_cpp_js_src31.o Unified_cpp_js_src32.o Unified_cpp_js_src33.o Unified_cpp_js_src34.o Unified_cpp_js_src35.o Unified_cpp_js_src36.o Unified_cpp_js_src37.o Unified_cpp_js_src38.o Unified_cpp_js_src39.o Unified_cpp_js_src4.o Unified_cpp_js_src40.o Unified_cpp_js_src5.o Unified_cpp_js_src6.o Unified_cpp_js_src7.o Unified_cpp_js_src8.o Unified_cpp_js_src9.o ../../config/external/ffi/libconfig_external_ffi.a ../../config/external/icu/libicu.a ../../config/external/fdlibm/libfdlibm.a ../../config/external/nspr/libnspr.a ../../config/external/zlib/libzlib.a > Executing: ar crs CTypes.o ConditionVariable.o Disassembler-x86-shared.o ExecutableAllocatorPosix.o Initialization.o Library.o MutexImpl.o Parser.o RegExp.o StoreBuffer.o Thread.o TraceLogging.o TraceLoggingGraph.o TraceLoggingTypes.o Unified_cpp_js_src0.o Unified_cpp_js_src1.o Unified_cpp_js_src10.o Unified_cpp_js_src11.o Unified_cpp_js_src12.o Unified_cpp_js_src13.o Unified_cpp_js_src14.o Unified_cpp_js_src15.o Unified_cpp_js_src16.o Unified_cpp_js_src17.o Unified_cpp_js_src18.o Unified_cpp_js_src19.o Unified_cpp_js_src2.o Unified_cpp_js_src20.o Unified_cpp_js_src21.o Unified_cpp_js_src22.o Unified_cpp_js_src23.o Unified_cpp_js_src24.o Unified_cpp_js_src25.o Unified_cpp_js_src26.o Unified_cpp_js_src27.o Unified_cpp_js_src28.o Unified_cpp_js_src29.o Unified_cpp_js_src3.o Unified_cpp_js_src30.o Unified_cpp_js_src31.o Unified_cpp_js_src32.o Unified_cpp_js_src33.o Unified_cpp_js_src34.o Unified_cpp_js_src35.o Unified_cpp_js_src36.o Unified_cpp_js_src37.o Unified_cpp_js_src38.o Unified_cpp_js_src39.o Unified_cpp_js_src4.o Unified_cpp_js_src40.o Unified_cpp_js_src5.o Unified_cpp_js_src6.o Unified_cpp_js_src7.o Unified_cpp_js_src8.o Unified_cpp_js_src9.o jsarray.o jsatom.o jsdtoa.o jsmath.o jsutil.o pm_linux.o tmpRC5Q8O/e_acos.o tmpRC5Q8O/e_acosh.o tmpRC5Q8O/e_asin.o tmpRC5Q8O/e_atan2.o tmpRC5Q8O/e_atanh.o tmpRC5Q8O/e_cosh.o tmpRC5Q8O/e_exp.o tmpRC5Q8O/e_hypot.o tmpRC5Q8O/e_log.o tmpRC5Q8O/e_log10.o tmpRC5Q8O/e_log2.o tmpRC5Q8O/e_pow.o tmpRC5Q8O/e_sinh.o tmpRC5Q8O/e_sqrt.o tmpRC5Q8O/k_exp.o tmpRC5Q8O/s_asinh.o tmpRC5Q8O/s_atan.o tmpRC5Q8O/s_cbrt.o tmpRC5Q8O/s_ceil.o tmpRC5Q8O/s_ceilf.o tmpRC5Q8O/s_copysign.o tmpRC5Q8O/s_expm1.o tmpRC5Q8O/s_fabs.o tmpRC5Q8O/s_floor.o tmpRC5Q8O/s_floorf.o tmpRC5Q8O/s_log1p.o tmpRC5Q8O/s_nearbyint.o tmpRC5Q8O/s_rint.o tmpRC5Q8O/s_rintf.o tmpRC5Q8O/s_scalbn.o tmpRC5Q8O/s_tanh.o tmpRC5Q8O/s_trunc.o tmpRC5Q8O/s_truncf.o RegExp.o CTypes.o Library.o Parser.o StoreBuffer.o ExecutableAllocatorPosix.o Disassembler-x86-shared.o jsarray.o jsatom.o jsdtoa.o jsmath.o jsutil.o pm_linux.o ConditionVariable.o MutexImpl.o Thread.o Initialization.o TraceLogging.o TraceLoggingGraph.o TraceLoggingTypes.o Unified_cpp_js_src0.o Unified_cpp_js_src1.o Unified_cpp_js_src10.o Unified_cpp_js_src11.o Unified_cpp_js_src12.o Unified_cpp_js_src13.o Unified_cpp_js_src14.o Unified_cpp_js_src15.o Unified_cpp_js_src16.o Unified_cpp_js_src17.o Unified_cpp_js_src18.o Unified_cpp_js_src19.o Unified_cpp_js_src2.o Unified_cpp_js_src20.o Unified_cpp_js_src21.o Unified_cpp_js_src22.o Unified_cpp_js_src23.o Unified_cpp_js_src24.o Unified_cpp_js_src25.o Unified_cpp_js_src26.o Unified_cpp_js_src27.o Unified_cpp_js_src28.o Unified_cpp_js_src29.o Unified_cpp_js_src3.o Unified_cpp_js_src30.o Unified_cpp_js_src31.o Unified_cpp_js_src32.o Unified_cpp_js_src33.o Unified_cpp_js_src34.o Unified_cpp_js_src35.o Unified_cpp_js_src36.o Unified_cpp_js_src37.o Unified_cpp_js_src38.o Unified_cpp_js_src39.o Unified_cpp_js_src4.o Unified_cpp_js_src40.o Unified_cpp_js_src5.o Unified_cpp_js_src6.o Unified_cpp_js_src7.o Unified_cpp_js_src8.o Unified_cpp_js_src9.o ../../modules/fdlibm/src/e_acos.o ../../modules/fdlibm/src/e_acosh.o ../../modules/fdlibm/src/e_asin.o ../../modules/fdlibm/src/e_atan2.o ../../modules/fdlibm/src/e_atanh.o ../../modules/fdlibm/src/e_cosh.o ../../modules/fdlibm/src/e_exp.o ../../modules/fdlibm/src/e_hypot.o ../../modules/fdlibm/src/e_log.o ../../modules/fdlibm/src/e_log10.o ../../modules/fdlibm/src/e_log2.o ../../modules/fdlibm/src/e_pow.o ../../modules/fdlibm/src/e_sinh.o ../../modules/fdlibm/src/e_sqrt.o ../../modules/fdlibm/src/k_exp.o ../../modules/fdlibm/src/s_asinh.o ../../modules/fdlibm/src/s_atan.o ../../modules/fdlibm/src/s_cbrt.o ../../modules/fdlibm/src/s_ceil.o ../../modules/fdlibm/src/s_ceilf.o ../../modules/fdlibm/src/s_copysign.o ../../modules/fdlibm/src/s_expm1.o ../../modules/fdlibm/src/s_fabs.o ../../modules/fdlibm/src/s_floor.o ../../modules/fdlibm/src/s_floorf.o ../../modules/fdlibm/src/s_log1p.o ../../modules/fdlibm/src/s_nearbyint.o ../../modules/fdlibm/src/s_rint.o ../../modules/fdlibm/src/s_rintf.o ../../modules/fdlibm/src/s_scalbn.o ../../modules/fdlibm/src/s_tanh.o ../../modules/fdlibm/src/s_trunc.o ../../modules/fdlibm/src/s_truncf.o > ar: CTypes.o: File format not recognized
This is slightly out-of-topic. Martin Stránský, could you rebase your repo to https://hg.mozilla.org/mozilla-central/rev/ebcbf47a83e7 or backport this changeset? That fixes building on Arch Linux (partially).
Summary: Make Firefox work as well with Wayland (without X) as with just X → Firefox Wayland port
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
Hi, I'm working on https://github.com/mozilla-japan/gecko-dev/commits/esr52-wayland-stransky to backport Stránský's patches in ESR52 branch. Now, this repo is still WIP.
Depends on: 1348990
The github repo (https://github.com/stransky/gecko-dev) has been synced with latest trunk and contains all available wayland patches. There are tree pre-built options if you're interested in testing the Wayland builds: Flatpak - https://firefox-flatpak.mojefedora.cz/ COPR repo - https://copr.fedorainfracloud.org/coprs/stransky/firefox-wayland/ src.rpm - https://stransky.fedorapeople.org/ I'm also very interested in any crashes / bugs, please report here or at bugzilla.redhat.com.
(In reply to Martin Stránský from comment #55) > I'm also very interested in any crashes / bugs, please report here or at > bugzilla.redhat.com. Thanks for this Martin. Flatpak Wayland build crashes regularly for me. However building from your source using the flatpak mozconfig is more stable, so it may be a flatpak issue? The one major issue I can see with my built version is that the menu when right-clicking a tab is blank (grey rather than white). All other right-click menus appear OK though.
(In reply to tarkasteve from comment #56) > (In reply to Martin Stránský from comment #55) > > I'm also very interested in any crashes / bugs, please report here or at > > bugzilla.redhat.com. > > Thanks for this Martin. > > Flatpak Wayland build crashes regularly for me. However building from your > source using the flatpak mozconfig is more stable, so it may be a flatpak > issue? Maybe, backtrace may be more helpful here although flatpak debugging is troublesome. I'd leave that for further investigation. > The one major issue I can see with my built version is that the menu when > right-clicking a tab is blank (grey rather than white). All other > right-click menus appear OK though. That's caused by missing wl_surface of associated GdkWindow. Needs to be fixed by better popup/seat management.
(In reply to Martin Stránský from comment #55) I'm seeing issues in HiDPI mode. The window content is scaled outside the window border: http://i.imgur.com/zrJXYT1.jpg The parts outside the window area are unresponsive, but I can 'control' the UI by clicking inside the windowed area (i.e. the content is scaled up but the input area is not. Debian Stretch / Gnome 3.22 / Intel HD.
tarkasteve: That appears to be the same issue I reported in https://bugzilla.mozilla.org/show_bug.cgi?id=1345666
Hi, testing latest flatpak version on my Debian Sid GNOME-Wayland 64 bits, I'm not able to customize Firefox using the dedicated button in the hamburger menu : nor the hamburger menu nor the toolbar can be customized. Thanks !
(In reply to Martin Stránský from comment #55) Paste (Ctrl-V) in a text box or area causes immediate lockup consistently. This is building from the firefox-wayland-55.7-1 using a production-esque .mozconfig.
(In reply to tarkasteve from comment #61) > (In reply to Martin Stránský from comment #55) > > Paste (Ctrl-V) in a text box or area causes immediate lockup consistently. > This is building from the firefox-wayland-55.7-1 using a production-esque > .mozconfig. Please file a new bug for that and assign it to me, this one is for tracking purpose only. Thanks!
Trying create a package for ArchLinux including your patches (https://aur.archlinux.org/packages/firefox-wayland-git). Unfortunately I this error: > /home/onny/projects/firefox-wayland-git/src/gecko-dev/obj-x86_64-pc-linux-gnu/_virtualenv/bin/python -m mozbuild.action.file_generate /home/onny/projects/firefox-wayland-git/src/gecko-dev/build/variables.py source_repo_header source-repo.h .deps/source-repo.h.pp > Traceback (most recent call last): > File "/usr/lib64/python2.7/runpy.py", line 174, in _run_module_as_main > "__main__", fname, loader, pkg_name) > File "/usr/lib64/python2.7/runpy.py", line 72, in _run_code > exec code in run_globals > File "/home/onny/projects/firefox-wayland-git/src/gecko-dev/python/mozbuild/mozbuild/action/file_generate.py", line 108, in <module> > sys.exit(main(sys.argv[1:])) > File "/home/onny/projects/firefox-wayland-git/src/gecko-dev/python/mozbuild/mozbuild/action/file_generate.py", line 63, in main > ret = module.__dict__[method](output, *args.additional_arguments) > File "/home/onny/projects/firefox-wayland-git/src/gecko-dev/build/variables.py", line 86, in source_repo_header > raise Exception('could not resolve changeset; ' > Exception: could not resolve changeset; try setting MOZ_SOURCE_CHANGESET I guess it's not related to your patches but do you know how to fix this?
Depends on: 1383156
(In reply to Jonas Heinrich from comment #63) > > Exception: could not resolve changeset; try setting MOZ_SOURCE_CHANGESET > I guess it's not related to your patches but do you know how to fix this? build/variables.py doesn't support getting the source changeset from a git checkout. So you can build from an hg checkout, or you can set MOZ_SOURCE_CHANGESET.
Depends on: 1396101
A few pointers for others trying to use and compile this branch (as of Nov 2017): 1. native compile on armhf: * runs out of memory (with 2GB RAM): use `ac_add_options --disable-debug-symbols` * fails because armcpudetect is defined twice (libvpx and libaom): use `ac_add_options --disable-av1` to disable libaom * fails compiling webrtc: use `ac_add_options --disable-webrtc` 2. firefox segmentation fault on start * no idea why, but using `firefox --no-remote` works 3. could not get WebGL working * for some reason, EGL_DEFAULT_DISPLAY was bogus, I had to use this patch: diff --git a/gfx/gl/GLLibraryEGL.cpp b/gfx/gl/GLLibraryEGL.cpp index 01bd3a7ff263..5546bd5c9257 100644 --- a/gfx/gl/GLLibraryEGL.cpp +++ b/gfx/gl/GLLibraryEGL.cpp @@ -511,7 +511,7 @@ GLLibraryEGL::EnsureInitialized(bool forceAccel, nsACString* const out_failureId mIsWARP = true; } } else { - chosenDisplay = GetAndInitDisplay(*this, EGL_DEFAULT_DISPLAY); + chosenDisplay = GetAndInitDisplay(*this, ((EGLNativeDisplayType)0)); } if (!chosenDisplay) { 4. video is not working, ffmpeg 3.3.4 installed (libavcodec57 7:3.3.4). any idea how to fix this one? [Child 1825, MediaPlayback #3] WARNING: Decoder=9d3da380 Decode error: NS_ERROR_DOM_MEDIA_FATAL_ERR (0x806e0005) - mozilla::MediaResult mozilla::FFmpegDataDecoder<57>::InitDecoder(): Couldn't initialise ffmpeg decoder: file /home/odroid/src/firefox/gecko-dev/dom/media/MediaDecoderStateMachine.cpp, line 3350 JavaScript warning: https://www.youtube.com/yts/jsbin/player-vfl8XKJyP/en_US/base.js, line 3233: Error: This error message will be blank when privacy.resistFingerprinting = true. If it is really necessary, please add it to the whitelist in MediaError::GetMessage: NS_ERROR_DOM_MEDIA_FATAL_ERR (0x806e0005) - mozilla::MediaResult mozilla::FFmpegDataDecoder<57>::InitDecoder(): Couldn't initialise ffmpeg decoder JavaScript warning: https://www.youtube.com/yts/jsbin/player-vfl8XKJyP/en_US/base.js, line 3233: Error: This error message will be blank when privacy.resistFingerprinting = true. If it is really necessary, please add it to the whitelist in MediaError::GetMessage: NS_ERROR_DOM_MEDIA_FATAL_ERR (0x806e0005) - mozilla::MediaResult mozilla::FFmpegDataDecoder<57>::InitDecoder(): Couldn't initialise ffmpeg decoder JavaScript warning: https://www.youtube.com/yts/jsbin/player-vfl8XKJyP/en_US/base.js, line 3233: Error: This error message will be blank when privacy.resistFingerprinting = true. If it is really necessary, please add it to the whitelist in MediaError::GetMessage: NS_ERROR_DOM_MEDIA_FATAL_ERR (0x806e0005) - mozilla::MediaResult mozilla::FFmpegDataDecoder<57>::InitDecoder(): Couldn't initialise ffmpeg decoder
(In reply to mihailescu2m from comment #65) > A few pointers for others trying to use and compile this branch (as of Nov > 2017): > > 1. native compile on armhf: > * runs out of memory (with 2GB RAM): use `ac_add_options > --disable-debug-symbols` > * fails because armcpudetect is defined twice (libvpx and libaom): use > `ac_add_options --disable-av1` to disable libaom > * fails compiling webrtc: use `ac_add_options --disable-webrtc` > > 2. firefox segmentation fault on start > * no idea why, but using `firefox --no-remote` works Can you please file #BZ for that and attach a backtrace there?
(In reply to Martin Stránský [:stransky] from comment #66) > Can you please file #BZ for that and attach a backtrace there? Bug ID #1416186 https://bugzilla.mozilla.org/show_bug.cgi?id=1416186 Trace: #0 0xb6ec5116 in __libc_do_syscall () at /lib/arm-linux-gnueabihf/libpthread.so.0 #1 0xb6ec4122 in raise () at /lib/arm-linux-gnueabihf/libpthread.so.0 #2 0xb2a13cca in nsProfileLock::FatalSignalHandler(int, siginfo_t*, void*) () at /usr/local/lib/firefox/libxul.so #3 0xb6c15890 in <signal handler called> () at /lib/arm-linux-gnueabihf/libc.so.6 #4 0xb61960f4 in XChangeProperty () at /usr/lib/arm-linux-gnueabihf/libX11.so.6 #5 0xb27fdff6 in XRemoteClient::DoSendCommandLine(unsigned long, int, char**, char const*, char**, bool*, char const*, char const*) () at /usr/local/lib/firefox/libxul.so #6 0xb27fe508 in XRemoteClient::SendCommandLine(char const*, char const*, char const*, int, char**, char const*, char**, bool*) () at /usr/local/lib/firefox/libxul.so #7 0xb2a192ae in XREMain::XRE_mainStartup(bool*) [clone .part.79] () at /usr/local/lib/firefox/libxul.so #8 0xb6f33ab8 in __stack_chk_guard () at /lib/ld-linux-armhf.so.3 Sorry there are no details because I used --no-debug-symbols to link it on 2GB RAM. Possible linked to #1359634 or #1360566 and #1360560
Assignee: nobody → stransky
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
Depends on: 1418792
Hi. Thanks for your work. I've compiled the Wayland branch (revision https://github.com/stransky/gecko-dev/commit/caf2a03e5e9e91635f9696e2ba0c9d522d3fc5e4) on my machine (FreeBSD 12-CURRENT, amdgpu, Mesa 17.3.0, Weston master). It works with software rendering, with some glitches (some elements on some pages flicker, keyboard input doesn't like to refresh the screen (so like, typing in a text field doesn't show up until scrolling or resizing the window), it's hard to focus items in context menus). But also, HiDPI works (which is the primary reason I want to switch to the Wayland native version ASAP), video playback works (including the AV1 demo). What doesn't work is EGL. In a debug build, the assertion at GLContextProviderEGL.cpp:177 (MOZ_ASSERT(aWindow)) fails. Makes sense, since the GET_NATIVE_WINDOW_… macros at the top of that file refer to X11 window IDs. In a non-debug build, "Failed to load EGL library 3". But after fixing EGL_DEFAULT_DISPLAY as suggested above by mihailescu2m, it's "Failed to create EGLSurface".
Looks like the window refresh problem is HiDPI related. It does not happen with scale=1 in Weston.
1513879786219 addons.xpi WARN Can't get modified time of /app/lib/firefox-59.0a1/browser/features/activity-stream@mozilla.org.xpi 1513879786222 addons.xpi WARN Can't get modified time of /app/lib/firefox-59.0a1/browser/features/aushelper@mozilla.org.xpi 1513879786224 addons.xpi WARN Can't get modified time of /app/lib/firefox-59.0a1/browser/features/firefox@getpocket.com.xpi 1513879786225 addons.xpi WARN Can't get modified time of /app/lib/firefox-59.0a1/browser/features/followonsearch@mozilla.com.xpi 1513879786226 addons.xpi WARN Can't get modified time of /app/lib/firefox-59.0a1/browser/features/formautofill@mozilla.org.xpi 1513879786227 addons.xpi WARN Can't get modified time of /app/lib/firefox-59.0a1/browser/features/onboarding@mozilla.org.xpi 1513879786229 addons.xpi WARN Can't get modified time of /app/lib/firefox-59.0a1/browser/features/presentation@mozilla.org.xpi 1513879786230 addons.xpi WARN Can't get modified time of /app/lib/firefox-59.0a1/browser/features/screenshots@mozilla.org.xpi 1513879786231 addons.xpi WARN Can't get modified time of /app/lib/firefox-59.0a1/browser/features/shield-recipe-client@mozilla.org.xpi 1513879786231 addons.xpi WARN Can't get modified time of /app/lib/firefox-59.0a1/browser/features/webcompat-reporter@mozilla.org.xpi 1513879786233 addons.xpi WARN Can't get modified time of /app/lib/firefox-59.0a1/browser/features/webcompat@mozilla.org.xpi 1513879786236 addons.xpi WARN Can't get modified time of /app/lib/firefox-59.0a1/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}.xpi 1513879822805 addons.xpi WARN Can't get modified time of /app/lib/firefox-59.0a1/browser/features/activity-stream@mozilla.org.xpi 1513879822806 addons.xpi WARN Can't get modified time of /app/lib/firefox-59.0a1/browser/features/aushelper@mozilla.org.xpi 1513879822806 addons.xpi WARN Can't get modified time of /app/lib/firefox-59.0a1/browser/features/firefox@getpocket.com.xpi 1513879822807 addons.xpi WARN Can't get modified time of /app/lib/firefox-59.0a1/browser/features/followonsearch@mozilla.com.xpi 1513879822807 addons.xpi WARN Can't get modified time of /app/lib/firefox-59.0a1/browser/features/formautofill@mozilla.org.xpi 1513879822807 addons.xpi WARN Can't get modified time of /app/lib/firefox-59.0a1/browser/features/onboarding@mozilla.org.xpi 1513879822808 addons.xpi WARN Can't get modified time of /app/lib/firefox-59.0a1/browser/features/presentation@mozilla.org.xpi 1513879822808 addons.xpi WARN Can't get modified time of /app/lib/firefox-59.0a1/browser/features/screenshots@mozilla.org.xpi 1513879822808 addons.xpi WARN Can't get modified time of /app/lib/firefox-59.0a1/browser/features/shield-recipe-client@mozilla.org.xpi 1513879822808 addons.xpi WARN Can't get modified time of /app/lib/firefox-59.0a1/browser/features/webcompat-reporter@mozilla.org.xpi 1513879822809 addons.xpi WARN Can't get modified time of /app/lib/firefox-59.0a1/browser/features/webcompat@mozilla.org.xpi 1513879822809 addons.xpi WARN Can't get modified time of /app/lib/firefox-59.0a1/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}.xpi (firefox:3): Gtk-WARNING **: cannot open display: I thought I should report this, because the flatpak version won't run unless I have an X11-based version open first. When I don't have an X11 one open, the above is what is spat out by the terminal. I'm on Antergos running the newest GNOME shell. I don't know why this happens. It's extremely frustrating given the speed boost of wayland. Any of you know if this should be filed in a separate bug, or is there something I can do separately to make this work? This is so weird...
(In reply to gagemorgan from comment #71) (the extension warnings are not relevant, you didn't have to paste them all) > (firefox:3): Gtk-WARNING **: cannot open display: It's not finding the display. Can you run other Wayland apps with Flatpak?
Could you give me an example of one? A quick browse through Flathub didn't really reveal which were actually Wayland and which were just XWayland.
(In reply to gagemorgan from comment #73) > Could you give me an example of one? A quick browse through Flathub didn't > really reveal which were actually Wayland and which were just XWayland. I'm sure any GNOME app would be sufficient, but you can test the de facto example of Flatpak GNOME apps (GNOME Recipes): https://flathub.org/repo/appstream/org.gnome.Recipes.flatpakref
Yeah, Gedit and friends all work just fine. It's only Firefox Nightly on Wayland that has this issue, via Flatpak of course.
Any update on enabling native Wayland support by default?
I tried the latest NightlyWayland flatpak and although it worked almost completely, for some reason no text would appear in the address bar as I typed. It was clearly accepting the input, because I could browse to pages, but I couldn't see what I was typing. Is this a known issue?
(In reply to jcdawes92 from comment #77) > for some reason no text would appear in the address bar as I > typed. It was clearly accepting the input, because I could browse to pages, > but I couldn't see what I was typing. Are you on a HiDPI display? When the compositor is at 2x scale, I see this. Text often only appears when you do some other action. Repaint/damage is broken on HiDPI :( Also EGL doesn't work for me.
(In reply to greg from comment #78) > (In reply to jcdawes92 from comment #77) > > for some reason no text would appear in the address bar as I > > typed. It was clearly accepting the input, because I could browse to pages, > > but I couldn't see what I was typing. > > Are you on a HiDPI display? When the compositor is at 2x scale, I see this. > Text often only appears when you do some other action. Repaint/damage is > broken on HiDPI :( > > Also EGL doesn't work for me. Yes, I know that. Filed as Bug 1429717. Thanks.
Priority: P5 → P2
Sorry for the delay in getting back to you. Yes, I am running HiDPI with scale 2.
Depends on: 1430775
All base patches are in tree which means the wayland port can be built/run now. (on glibc systems only due to Bug 1409707). All you need is to build trunk with: ac_add_options --enable-default-toolkit=cairo-gtk3-wayland
@Martin Building it with this option means that it will run on both X and WL like all gtk apps do?
(In reply to ApB from comment #82) > @Martin > > Building it with this option means that it will run on both X and WL like > all gtk apps do? Yes.
(In reply to Martin Stránský [:stransky] from comment #83) > (In reply to ApB from comment #82) > > @Martin > > > > Building it with this option means that it will run on both X and WL like > > all gtk apps do? > > Yes. Makes sense to be made default then. At least for trunk.
Depends on: 1420555
Target Milestone: --- → mozilla59
"Target Milestone: --- → mozilla59" are you considering Wayland to be stable for 59?
Flags: needinfo?(stransky)
(In reply to Sylvestre Ledru [:sylvestre] from comment #85) > "Target Milestone: --- → mozilla59" > are you considering Wayland to be stable for 59? Sorry If set the flag wrongly. I mean 59 has a basic support and it's roughly functional but not good enough for general audience. I'm going to file another bug "Ship wayland builds to user" like we had for Gtk3 (Bug 1193807) and manage the stable status there.
Flags: needinfo?(stransky)
Thanks for clarification. I reset the flag. Meta bugs usually should only have a target milestone when the feature completely shipped.
Target Milestone: mozilla59 → ---
No longer blocks: 1215085
Depends on: 1215085
Just wanted to say thanks to everyone working to move this forward, it's really important work! Hopefully cheerleading isn't too offtopic!
(In reply to Martin Stránský [:stransky] (Back on Feb 12) from comment #81) > All base patches are in tree... (In reply to Martin Stránský [:stransky] (Back on Feb 12) from comment #86) > ... 59 has a basic support and it's > roughly functional but not good enough for general audience. Does the current Nightly ship with Wayland support enabled already? I have tried it just now, but it does not seem to work: $ GDK_BACKEND=wayland firefox Error: no DISPLAY environment variable specified BTW, is there a simple way to see the build-time configuration of a firefox binary?
(In reply to pbasista from comment #89) > BTW, is there a simple way to see the build-time configuration of a firefox > binary? Maybe about:buildconfig?
(In reply to Laurentiu Nicola from comment #90) > Maybe about:buildconfig? Thanks, I did not know about it. I was expecting some command-line way, in case the GUI is not available. Anyway... It contains the configure options: MOZ_AUTOMATION=1 --enable-update-channel=nightly MOZILLA_OFFICIAL=1 MOZ_PGO=1 CC=/builds/worker/workspace/build/src/gcc/bin/gcc CXX=/builds/worker/workspace/build/src/gcc/bin/g++ MOZ_STDCXX_COMPAT=1 --enable-js-shell RUSTC=/builds/worker/workspace/build/src/rustc/bin/rustc CARGO=/builds/worker/workspace/build/src/rustc/bin/cargo --with-mozilla-api-keyfile=/builds/mozilla-desktop-geoloc-api.key --with-google-api-keyfile=/builds/gapi.data LLVM_CONFIG=/builds/worker/workspace/build/src/clang/bin/llvm-config --enable-rust-simd MAKE=/usr/bin/make --enable-crashreporter --enable-verify-mar --with-branding=browser/branding/nightly But I am not able to use that info for determining whether the Wayland support is built-in or not.
(In reply to pbasista from comment #89) > Does the current Nightly ship with Wayland support enabled already? I have > tried it just now, but it does not seem to work: > No, it doesn't. You need to add --enable-default-toolkit=cairo-gtk3-wayland to the build options to do so.
(In reply to Jan Horak [:jhorak] from comment #92) > (In reply to pbasista from comment #89) > > Does the current Nightly ship with Wayland support enabled already? I have > > tried it just now, but it does not seem to work: > > > No, it doesn't. You need to add --enable-default-toolkit=cairo-gtk3-wayland > to the build options to do so. Ok, thanks. Do you know why it has not been enabled? BTW, how can one, in general, verify whether a particular build-time configuration option is currently used for building the official Nightly binaries?
(In reply to pbasista from comment #93) > Ok, thanks. Do you know why it has not been enabled? Because there are 14 open bugs that block this one. You can see them at the top right on the Dependency list. > BTW, how can one, in general, verify whether a particular build-time > configuration option is currently used for building the official Nightly > binaries? about:buildconfig shows you the options.
On Plasma 5.12 on Wayland only a blank page is rendered, mouse input is not accepted and the mouse cursor is invisible.
I have just tried a custom build of Firefox Nightly on Wayland, with no additional custom configure options, and it works more or less fine in Gnome 3 on a non-hidpi display (from what I could see). In Weston, there are some strange issues: 1. Unable to click on any main menu item (Add-ons, Preferences, Customize) or buttons in the pop-up dialogs (e.g. to confirm installation of an add-on). Trying to "click" the highlighted option by pressing Enter does not seem to have any effect either. 2. Crash when switching YouTube from fullscreen back to normal mode. There is still no opengl compositing on Linux, which is unfortunate, because of a massive positive impact it would have - i.e. a "smooth" user experience. But the fact that Wayland part seems to be on its way to work fine is definitely great.
Yeah, about OpenGL compositing (and WebGL, and WebRender). That needs Wayland-EGL support. Looks like the first problem is that EGL initialization is called with EGL_DEFAULT_DISPLAY instead of a wl_display. I've attempted to fix that: https://gist.github.com/myfreeweb/99f2df1a29652c0b75f2799e4b1aad38 but that's not enough. A wl_egl_window should be created to render EGL to a surface. I'm not familiar with Firefox code at all, so I couldn't make all that stuff work.
(In reply to greg from comment #97) > Yeah, about OpenGL compositing (and WebGL, and WebRender). That needs > Wayland-EGL support. > > Looks like the first problem is that EGL initialization is called with > EGL_DEFAULT_DISPLAY instead of a wl_display. I've attempted to fix that: > https://gist.github.com/myfreeweb/99f2df1a29652c0b75f2799e4b1aad38 but > that's not enough. A wl_egl_window should be created to render EGL to a > surface. I'm not familiar with Firefox code at all, so I couldn't make all > that stuff work. Can you please file a new bug for it? To have it properly tracked.
Flags: needinfo?(greg)
Depends on: 1438144
No longer blocks: 1440283
Depends on: 1440283
Depends on: 1441743
Any updates on bug 1438144 and bug 1429717?
Flags: needinfo?(greg)
Depends on: 1451816
Depends on: 1455571
Depends on: 1456025
hm, after recent changes, my build fails with '/usr/bin/ld: error: undefined symbol: mozilla::gl::sGLXLibrary'
@greg Confirming, same issue.
(In reply to greg from comment #100) > hm, after recent changes, my build fails with '/usr/bin/ld: error: undefined > symbol: mozilla::gl::sGLXLibrary' That's because missing patches from Bug 1460255 - I'll post updated ones there.
Depends on: 1464808
Depends on: 1464814
Depends on: 1464823
Depends on: 1464826
Depends on: 1464994
Depends on: 1466386
Depends on: 1466444
Depends on: 1468670
Depends on: 1469187
Depends on: 1470047
Hi, I'm not sure where to report it, but since a few days ago visiting maps.google.com with Firefox 60.0.2 on Linux (Debian unstable of today, Linux 4.16.16-2) under Wayland (1.15.0-2, xwayland 1.20.0-2) crashes Firefox and my whole computer with it. There's nothing in logs written to disk during this crash. I would have to setup some remote logging to have a chance to see something. This is on a laptop with an Intel video controller.
@Raphaël Hertzog Can you check if there's anything in about:crashes? You should probably look for, or file a new issue for this.
##### begin offtopic to this thread ##### @Raphael, Hertzog, you've hit an xwayland mesa bug. Here is the bug I filed against mozilla https://bugzilla.mozilla.org/show_bug.cgi?id=1468930, but it's not firefox's problem, they are just triggering it. The real issue was found and is already fixed in arch and Redhat linux. https://bugzilla.redhat.com/show_bug.cgi?id=1579067 Debian users are hitting the bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901928 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901883 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901497 To fix someone at Debian X-strikeforce has to also patch xwayland and rebuild. Looks like that just happened: https://salsa.debian.org/xorg-team/xserver/xorg-server/merge_requests/2 The changes have been built but have not yet been pushed into the unstable repo yet though as of when I just checked. It should be something like 1.20.0-3 when someone pushes it. If you are antsy, or dont want to run Chrome for a couple days, or don't want to switch back to X.org without wayland for a couple days, you CAN learn how to build the debian X.org packages after applying the two needed patches using deb-src (that's what I am running the last few days, and no crashes). It's not really that hard, like 4 terminal commands. ###### end offtopic to this thread #####
Hi, thanks to everyone who has been working on this feature. As far as I can tell from reading the bug comments, the current state is that (preliminary) Wayland support has been merged into the source tree but is not enabled on Nightly builds. What would have to happen to enable this feature in Nightly builds? Is there a plan to do so in the near future, or is that a longer-term item?
@hdevalence I'm pretty sure it's been enabled by default in Nightly since bug 1460255 landed. I used to have 'ac_add_options --with-gl-provider=EGL' in .mozconfig, but I've commented it out a while ago and and rebuilt many times and Wayland support does work.
@greg I don't think so. The nightlies are still using Xwayland.
(In reply to hdevalence from comment #107) > Hi, thanks to everyone who has been working on this feature. > > As far as I can tell from reading the bug comments, the current state is > that (preliminary) Wayland support has been merged into the source tree but > is not enabled on Nightly builds. What would have to happen to enable this > feature in Nightly builds? Is there a plan to do so in the near future, or > is that a longer-term item? That's a good question, IMHO there are still some outstanding issues which need to be fixed first, for instance Bug 1430775 Bug 1431399 Bug 1466295 Bug 1466444 Bug 1467132 Bug 1468911 Bug 1470047
@Martin: As long as the the normal Nightly builds are not are not providing Wayland, can we continue to use the Nightly builds from https://firefox-flatpak.mojefedora.cz/? I had the feeling my flatpak build (org.mozilla.FirefoxNightly) didn't get updated anymore, but this could be an issue on my end. From my point of view as a normal user I don't see features like WebRTC, which is still WIP in Gnome and KDE, as essential for providing Wayland with the normal builds, some limitations are expected. Thanks
(In reply to rainer from comment #111) > @Martin: As long as the the normal Nightly builds are not are not providing > Wayland, can we continue to use the Nightly builds from > https://firefox-flatpak.mojefedora.cz/? I had the feeling my flatpak build > (org.mozilla.FirefoxNightly) didn't get updated anymore, but this could be Flatpak at https://firefox-flatpak.mojefedora.cz/ is active and should be updated, I'll check that. Also Fedora provides Wayland enabled Firefox as an option by firefox-wayland package.
Mark one more vote from me for going ahead and building nightly with Wayland support -- behind a commandline switch of course at first. Most linux users are capable of setting and environment variable, or typing a commandline switch, but even most experienced users are going to balk at building firefox themselves because of the build environment complexity. Jumping over to a second install via flatpack is a possible solution, but you'd get a lot more testing by letting the whole Nightly community opt in when they want to. After all, the idea with Nightly is the ability to help with the latest features, and getting the new code every day. I'd join the testing team then.
Not sure if this would be feasible at all, but how about a flag that can be easily set under about:config and gets checked for at startup? If I understand correctly this will be the eventual goal anyway, to check on startup whether Wayland is available or not and then accordingly start either with Xorg or Wayland backend.
Do we really need a new option that needs to be set in "about:config"? Why not rely on XDG_SESSION_TYPE and a simple logic to use a fallback if this environment variable is not set...
Not sure if I make something wrong, but my Firefox-nightly flatpak is not getting updated anymore. $ flatpak run org.mozilla.FirefoxNightly -v Mozilla Firefox 62.0a1
(In reply to Markus Rathgeb from comment #115) > Do we really need a new option that needs to be set in "about:config"? Why > not rely on XDG_SESSION_TYPE and a simple logic to use a fallback if this > environment variable is not set... Maybe because it's too experimental to be enabled in nightly by default? (In reply to rainer from comment #116) > Not sure if I make something wrong, but my Firefox-nightly flatpak is not > getting updated anymore. > $ flatpak run org.mozilla.FirefoxNightly -v > Mozilla Firefox 62.0a1 See comment #112. The nightly repo hasn't seen regular builds in a while.
would love just setting XDG_SESSION_TYPE to try the pure wayland builds.
(In reply to Christian Stadelmann from comment #117) > Maybe because it's too experimental to be enabled in nightly by default? Yes, that was the thought process. Using XDG_SESSION_TYPE would make it the default for everyone running a Wayland session, which reasonably does not seem to be desired according to comment #110. However more people can be reached, since it is (even) simpler than installing the flatpak version.
ah, well then let's make it a commandline switch or a different variable untill the feature is stable.
As the flatpak builds are quite outdated, I would welcome if Firefox-nightly would provide Wayland support by default for testing. I don't think that there is a need for any other switch than what is used by Gtk other applications. Something like "GDK_BACKEND=wayland firefox-nightly" or "GDK_BACKEND=x11 firefox-nightly" should be enough.
I'd like to reference #1474281 as blocker, as we shouldn't turn on the wayland-backend by default before it is tackled.
Anyone else getting similar crashes? #0 0xb5001282 in get_window_target_buffer () at /usr/lib/arm-linux-gnueabihf/libwayland-egl.so.1 #1 0xb4ff8cf4 in eglp_window_next_render_target () at /usr/lib/arm-linux-gnueabihf/libwayland-egl.so.1 #2 0xb4ff8f6c in eglp_first_operation_cb () at /usr/lib/arm-linux-gnueabihf/libwayland-egl.so.1 #3 0xb5019522 in gles_fbp_prepare_to_render () at /usr/lib/arm-linux-gnueabihf/libwayland-egl.so.1 #4 0xb501c3e4 in gles_fbp_clear () at /usr/lib/arm-linux-gnueabihf/libwayland-egl.so.1 #5 0xb50171a2 in gles_fb_clear () at /usr/lib/arm-linux-gnueabihf/libwayland-egl.so.1 #6 0xb12da900 in mozilla::layers::CompositorOGL::BeginFrame(mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const*, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const&, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits>*, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits>*) () at /mnt/disk1/src/firefox-62.0/debian/tmp/usr/lib/firefox/libxul.so #7 0xb12da6f0 in mozilla::layers::CompositorOGL::BeginFrame(mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const*, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const&, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits>*, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits>*) () at /mnt/disk1/src/firefox-62.0/debian/tmp/usr/lib/firefox/libxul.so #8 0xb1369670 in mozilla::layers::LayerManagerComposite::Render(mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&) () at /mnt/disk1/src/firefox-62.0/debian/tmp/usr/lib/firefox/libxul.so #9 0x00000000 in () firefox 62, armhf, mali T628 drivers r12p0
Depends on: 1480053
Depends on: 1489902
Depends on: 1492774
Depends on: 1493493
Depends on: 1500415
Anyone working on HiDPI+EGL support?
(In reply to greg from comment #126) > Anyone working on HiDPI+EGL support? I have investigated to a issue with windows rendering. On HIDPI screens with enabled OGL compositor firefox displays one fourth of windows/popups only. Here my simple patch, which solve the issue https://gist.github.com/IShashkin/ad33a8fd55290065fabfcf174db3ebd5 But i need help with upstreaming the patch, because i'm new in a contributing to firefox.
> I have investigated to a issue with windows rendering. On HIDPI screens with enabled OGL compositor firefox displays one fourth of windows/popups only. Here my simple patch, which solve the issue https://gist.github.com/IShashkin/ad33a8fd55290065fabfcf174db3ebd5 Good Job! > But i need help with upstreaming the patch, because i'm new in a contributing to firefox. Please read this: https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Introduction Probably the first thing you need to do is finding or creating a bug for this issue. Next, attach your patch to the bug, or post it to Mozilla's Phabricator: https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html Then send a review request (assign a reviewer for the patch). Probably stransky or jhorak are suitable reviewers for this patch if you follow the precedent commits around this code.
Sure, I'm keen to review it.
(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..
(In reply to Takuro Ashie [:ashie] from comment #128) Thanks for the advice! (In reply to greg from comment #130) > Thanks! Unfortunately it's still very buggy, especially with multiple > monitors (one 1x scale, one 2x) and with popovers.. Oh, then i'll continue a debug of the issue.
Depends on: 1507817
Thanks, just saw https://www.phoronix.com/scan.php?page=news_item&px=Firefox-Nightly-Ships-Wayland and updated nightly, and set GDK_BACKEND=wayland to try it. So far everything works great, but how do I confirm that I am running under nativ Wayland? xeyes for instance still moves its eyes when I hover the mouse, over nightly, so I am suspicious...
So to answer my own question, Got this from here: https://glandium.org/blog/?p=3899 "To verify whether Wayland support is enabled, go to about:support, and check “WebGL 1 Driver WSI Info” and/or “WebGL 2 Driver WSI Info”. If they say something about GLX, Wayland support is not enabled. If they say something about EGL, it is. I filed a bug to make it more obvious what is being used."
(In reply to yareckon from comment #133) > So to answer my own question, Got this from here: > https://glandium.org/blog/?p=3899 > > "To verify whether Wayland support is enabled, go to about:support, and > check “WebGL 1 Driver WSI Info” and/or “WebGL 2 Driver WSI Info”. If they > say something about GLX, Wayland support is not enabled. If they say > something about EGL, it is. I filed a bug to make it more obvious what is > being used." On Wayland you'll see EGL_WL_bind_wayland_display or similar Wayland extensions available at about:support.
> how do I confirm that I am running under nativ Wayland In Gnome Shell, you can press ALT-F2, type "lg", click on "Windows", look for Firefox, click on it, then check if the first line says MetaWindowWayland (good) or MetaWindowXwayland (bad). Under Wayland you'll also notice that wheel scrolling is smoother (pixel instead of line-based). :stransky, is it possible that some part of Firefox makes XWayland start? I tried to run it, noticed the smoother scrolling, but didn't check what Gnome says about the window. I'm not going to use the Wayland support until it plays well with HW compositing.
(In reply to Laurentiu Nicola from comment #135) > :stransky, is it possible that some part of Firefox makes XWayland start? I > tried to run it, noticed the smoother scrolling, but didn't check what Gnome > says about the window. I'm not going to use the Wayland support until it > plays well with HW compositing. I guess flash-plugin would need that but you may have Xwayland by default, check your DISPLAY env variable. Wayland uses WAYLAND_DISPLAY.
> I'm not going to use the Wayland support until it plays well with HW compositing. bug 1474281 might help with that.
(In reply to yareckon from comment #132) > Thanks, just saw > https://www.phoronix.com/scan.php?page=news_item&px=Firefox-Nightly-Ships- > Wayland and updated nightly, and set GDK_BACKEND=wayland to try it. So far > everything works great, but how do I confirm that I am running under nativ > Wayland? xeyes for instance still moves its eyes when I hover the mouse, > over nightly, so I am suspicious... Another way to differentiate - run xwininfo. You won't be able to click on Wayland windows. The cursor will change to a crosshair over xwayland windows and you'll be able to click them in order to get their properties.
(In reply to ame from comment #138) > Another way to differentiate - run xwininfo. If you're in the command-line, `xlsclients` is probably simpler. Firefox shouldn't be listed.
Depends on: 1508378
Depends on: 1508594
Depends on: 1507766
Depends on: 1507764
Depends on: 1507763
Blocks: 1509152
No longer blocks: 1509152
Depends on: 1509152
Depends on: 1508357
Depends on: 1509275
Depends on: 1509740
Depends on: 1509931
Depends on: 1509937
Depends on: 1508803
Not *directly* related to Wayland (works on X11 too), but would be very very nice for Wayland users with touchpads: https://bugzilla.mozilla.org/show_bug.cgi?id=1213601 can someone please implement the conversion from GDK scroll events to APZ events in order to get us kinetic (inertial) scrolling?
Depends on: 1513225
Depends on: 1514053
No longer depends on: 1514053
Could someone confirm that using nightly without a titlebar works on Wayland?? Tried on weston and the titlebar wasn't going away neither the images for the buttons were working.
(In reply to ApB from comment #141) > Could someone confirm that using nightly without a titlebar works on > Wayland?? Tried on weston and the titlebar wasn't going away neither the > images for the buttons were working. Please file that as Weston specific bug - I don't see any such issue on mutter/gnome-shell.
(In reply to Martin Stránský [:stransky] from comment #142) > (In reply to ApB from comment #141) > > Could someone confirm that using nightly without a titlebar works on > > Wayland?? Tried on weston and the titlebar wasn't going away neither the > > images for the buttons were working. > > Please file that as Weston specific bug - I don't see any such issue on > mutter/gnome-shell. I see the same thing in Enlightenment also.
I've been using it without a titlebar for a long time, with the MOZ_GTK_TITLEBAR_DECORATION=client environment variable
(on Weston) Maybe there's some "desktop environment detection" that enables CSD automatically without the environment variable?
(In reply to greg from comment #144) > I've been using it without a titlebar for a long time, with the > MOZ_GTK_TITLEBAR_DECORATION=client environment variable Yep. Works with that both on E and Weston. No idea what mutter does differently and doesn't require an env there. But anyway shouldn't this be the default behavior on all wayland desktops since AFAIK wayland is client side only??
(In reply to ApB from comment #146) > No idea what mutter does differently and doesn't require an env there. Maybe Firefox specifically checks whether it's running in GNOME. I recently reported a bug to LibreOffice — without GDK_BACKEND=wayland, it would try to detect the desktop environment, and if running without a known DE it would just go into batch server mode and not draw a GUI at all :D > AFAIK wayland is client side only?? Wayland doesn't dictate this at all, but the general convention has been "client side by default". KDE has introduced a negotiation protocol: https://github.com/KDE/kwayland/blob/master/src/client/protocols/server-decoration.xml (supported in KWin and Sway at least) GTK supports it since 3.22.25: https://gitlab.gnome.org/GNOME/gtk/commit/f2adaba237519642b88ccb42b47a95cf539a2a12
(In reply to greg from comment #147) > (In reply to ApB from comment #146) > > No idea what mutter does differently and doesn't require an env there. > > Maybe Firefox specifically checks whether it's running in GNOME. > It should have the same behavior across all wayland desktops. It is a bug if it doesn't.
(In reply to ApB from comment #148) > (In reply to greg from comment #147) > > (In reply to ApB from comment #146) > > > No idea what mutter does differently and doesn't require an env there. > > > > Maybe Firefox specifically checks whether it's running in GNOME. > > > > It should have the same behavior across all wayland desktops. It is a bug if > it doesn't. Filed as Bug 1514828.
Depends on: 1515402
Depends on: 1517205
Depends on: 1518427
Depends on: 1519940

(In reply to ApB from comment #141)

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

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

path=GTK_THEME=Adwaita MOZ_GTK_TITLEBAR_DECORATION=client firefox

Keywords: meta
Summary: Firefox Wayland port → [meta] Firefox Wayland port
Depends on: 1525213
Depends on: 1527556
Depends on: 1527804
Depends on: 1528105
Depends on: 1528581
Depends on: 1528021
Depends on: 1528733
Depends on: 1530018
Depends on: 1530114
Depends on: 1530201
Depends on: 1531300
Depends on: 1532024
Depends on: 1532618
Depends on: 1532627
Depends on: 1532949
Depends on: 1534557
Depends on: 1534585
Depends on: 1534936
No longer blocks: 1534963
Depends on: 1534963
Depends on: 1535561
Depends on: 1535565
Depends on: 1535568
Depends on: 1535893
Depends on: 1536010
Depends on: 1536747
Depends on: 1538052
Depends on: 1500698
No longer depends on: 1500698
Depends on: 1538551
Depends on: 1539773
No longer blocks: 1418611
Depends on: 1418611
No longer depends on: 1515402
Regressions: 1515402
No longer depends on: 1541003
Regressions: 1541003
No longer depends on: 1539773
Regressions: 1539773
Depends on: 1542808
No longer depends on: 1543687
Regressions: 1543687
No longer depends on: 1543035
Regressions: 1543035
Depends on: 1545927

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

But yes there are no wrong positioning anymore.

(In reply to hoshiyamazaki01 from comment #151)

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

But yes there are no wrong positioning anymore.

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

Flags: needinfo?(hoshiyamazaki01)
Depends on: 1548499
Depends on: 1548496
Depends on: 1549099
Depends on: 1550658
Regressions: 1551255
Depends on: 1551255
No longer regressions: 1551255
Depends on: 1552020
No longer depends on: 1552020
Depends on: 1554677

Just a question:

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

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

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

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

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

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

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

Firefox still relies on X11 for testing whether acceleration works

bug 1548911 was fixed 3 days ago.

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

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

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

Thank both of You!

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

bug 1548911 was fixed 3 days ago.

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

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

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

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

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

Just a question:

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

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

Filed as Bug 1556301.

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

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

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

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

Depends on: 1559912
Depends on: 1560082
Depends on: 1560103
Depends on: 1560545
Depends on: 1562576
Depends on: 1562662
Depends on: 1563075
Depends on: 1564720
Depends on: 1565785
Depends on: 1553887
Depends on: 1567434
Depends on: 1567463
Depends on: 1567106
Depends on: 1575171
Depends on: 1576268
Depends on: 1577056
Depends on: 1577589
No longer depends on: 1577056
Depends on: 1578167

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

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

Depends on: 1580595
Depends on: 1581773
Depends on: 1583035

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

Depends on: 1584503
Depends on: 1584511
Depends on: 1584756
Depends on: 1585918
Depends on: 1587360
Depends on: 1588200
Depends on: 1588129
Depends on: 1588987
Depends on: 1589114
Depends on: 1589245
No longer depends on: 1588913
Depends on: 1589601
Depends on: 1589611
Depends on: 1590498
Depends on: 1590586

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

Depends on: 1591716
Depends on: 1593408
Depends on: 1600261
Depends on: 1601082
Depends on: 1602309
Depends on: 1603927
Depends on: 1604048
Depends on: 1605795
Depends on: 1605893
Depends on: 1605906
Depends on: 1604948
Depends on: 1606010
Depends on: 1606776
Depends on: 1606941
Depends on: 1607399
Depends on: 1608016
Depends on: 1609040
Depends on: 1609538
Depends on: 1592458
Depends on: 1611974
Depends on: 1618594
Depends on: 1619818
Depends on: 1620180
Depends on: 1621660
Depends on: 1622107
Depends on: 1618093
Depends on: 1622559
No longer depends on: 1622700
Depends on: 1623773
Depends on: 1620076
Depends on: 1625253
Depends on: 1625849
Depends on: 1625664
Depends on: 1629140
Depends on: 1627717
Depends on: 1630251
No longer depends on: 1630251
Depends on: 1611774
Depends on: 1373752
Depends on: 1625882
Depends on: 1634404
No longer depends on: 1575171
Depends on: 1575171
Depends on: 1638084
Depends on: 1640053
Depends on: 1640651
Depends on: 1640094
Depends on: 1641033
Depends on: 1641458
Depends on: 1641462
Depends on: 1641749
No longer depends on: 1641458
Depends on: 1618914
Depends on: 1643149
Depends on: 1643219
Depends on: 1643993
Depends on: 1640567
See Also: → 1645528
Depends on: 1645528
See Also: 1645528
Depends on: 1645600
Depends on: 1645693
Depends on: 1645695
Depends on: 1645739
Depends on: 1647072

What version will have this enabled by default?

(In reply to romulasry from comment #163)

What version will have this enabled by default?

Found the bug: 1543600

(In reply to romulasry from comment #163)

What version will have this enabled by default?

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

No longer depends on: 1634404
Depends on: 1648698
Depends on: 1646202
Depends on: 1653832
No longer depends on: 1653832
Depends on: 1654706
Depends on: 1655282
Depends on: 1655366
No longer depends on: 1655366
Depends on: 1655366
Depends on: 1656721
Depends on: 1656727
Blocks: 1373752
No longer depends on: 1373752
Depends on: 1663328
Depends on: 1667674
Depends on: 1667444
Depends on: 1667851
Depends on: 1668805
No longer depends on: 1656721
Depends on: 1670731
Depends on: 1672234
No longer depends on: 1672234
Depends on: 1672633
Depends on: 1673000
Depends on: 1673862
Depends on: 1675402
Depends on: 1678840
Depends on: 1677351
Depends on: 1677361
Depends on: 1679215
Depends on: 1679755
Depends on: 1680954
Depends on: 1680961
Depends on: 1681018
Depends on: 1681230
Depends on: 1683270
No longer depends on: 1683270
No longer depends on: 1680961
Depends on: 1682852
Depends on: 1685409
Depends on: 1685689
Depends on: 1685694
Depends on: 1690999
Depends on: 1692451
No longer depends on: 1689207
Depends on: 1694038
Depends on: 1694258
Depends on: 1695227
No longer depends on: 1692451
Depends on: 1695453
Depends on: 1696876
Depends on: 1699942
Depends on: 1701977
No longer depends on: 1701977
Depends on: 1702853
Depends on: 1702854

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

Depends on: 1704290
Depends on: 1705048
Depends on: 1700686
Depends on: 1701845
Depends on: 1706605
Depends on: 1706452
Depends on: 1707124
Depends on: 1661450
Depends on: 1707209
Depends on: 1707226
Depends on: 1708416
Depends on: 1707833
Depends on: 1710197

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

Depends on: 1715986
Depends on: 1716191
Depends on: 1714839
Depends on: 1713686
Depends on: 1717351
Depends on: 1717391
Depends on: 1719894
Depends on: 1720646
Depends on: 1720887
No longer blocks: 1712969
Depends on: 1720874
Depends on: 1721563
Depends on: 1721707
Depends on: 1722480
Depends on: 1722700
Depends on: 1723383
Depends on: 1722369
No longer depends on: 1723940
Depends on: 1724242
Depends on: 1726923
Depends on: 1728891
Depends on: 1731156
Depends on: 1730114
Depends on: 1731428
Depends on: 1731489
Depends on: 1734566
Depends on: 1706940
Depends on: 1735377
Depends on: 1644606
Depends on: 1736209
Depends on: 1588950
Depends on: 1738066
Depends on: 1738299
Depends on: 1738639
Depends on: 1739137
Depends on: 1739142
Depends on: 1739339
Depends on: 1739598
Depends on: 1739600
Depends on: 1739604
Depends on: 1739622
Depends on: 1739647
Depends on: 1739783
Depends on: 1739780
Depends on: 1740124
Depends on: 1710344
Depends on: 1742225
See Also: → tbwayland
No longer depends on: 1716172
No longer depends on: 1739137
Depends on: 1737124
Depends on: 1675680
Depends on: 1744801
Depends on: 1744800
Depends on: 1744896
Depends on: 1745098
Depends on: 1745560
Depends on: 1745894
Depends on: 1746715
Depends on: 1737834
Depends on: 1748800
Depends on: 1747641
Depends on: 1747524
No longer depends on: 1747524
No longer depends on: 1747641

I believe #1750237 belongs here too.

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

Depends on: 1756100

Depends on: 1754555
Depends on: 1756841
Depends on: 1758094
No longer depends on: 1752113
Depends on: 1764522
Depends on: 1767142
Depends on: 1768459
Depends on: 1768177
No longer depends on: 1768487
Depends on: 1769530
No longer depends on: 1769530
Depends on: 1769069
No longer depends on: 1769069
Depends on: 1767916
Depends on: 1769268
No longer depends on: 1768358
Depends on: 1769890
Depends on: 1771017

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

For more information, please visit auto_nag documentation.

Flags: needinfo?(hoshiyamazaki01) → needinfo?(bhood)
Component: Graphics → Widget: Gtk
Flags: needinfo?(bhood)
Depends on: 1773844
Depends on: 1774556
Depends on: 1775256
Depends on: 1775266
Depends on: 1775325
No longer depends on: 1775002
Depends on: 1777393
Depends on: 1778837
Depends on: 1782522
Depends on: 1783829
Depends on: 1786247
Depends on: 1789558
Depends on: 1791129

FYI: bug 1792617 is Wayland specific.

Severity: normal → S3
Depends on: 1788205
No longer depends on: 1788205
Depends on: 1794577
Depends on: 1797469
Depends on: 1797978
Depends on: 1799575
Depends on: 1804973
Depends on: 1805208
Depends on: 1803016
Depends on: 1805776
Depends on: 1809350
Depends on: 1823063
No longer depends on: 1823063
Depends on: 1824304
Depends on: 1824552
No longer depends on: 1822764
No longer depends on: 1806276
Depends on: 1783414
Depends on: 1826583
Depends on: 1827446
No longer depends on: 1794266
Depends on: 1676705
Depends on: 1828618
Depends on: 1828772
Depends on: 1830215
Depends on: 1831051

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

Depends on: 1831557
Depends on: 1832054
Depends on: 1834589
Depends on: 1834563
Depends on: 1841851
Depends on: 1850114
Depends on: 1850285
Depends on: 1850697
Depends on: 1850318
Depends on: 1854920
Depends on: 1744536
Depends on: 1871757
Depends on: 1872949
Depends on: 1873220
No longer depends on: 1873220
Depends on: 1874717
Depends on: 1784438
Depends on: 1885765
Depends on: 1896457
Depends on: 1902216
No longer depends on: 1904265
Depends on: 1921677
Depends on: 1923568
Depends on: 1933823
Depends on: 1934542
No longer depends on: 1832876
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: