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