User says: """I don't remember, that I did some drag and drop. The only thing a remember was watching a video on Youtube. :-( No, I could not reproduce it.""" Truncated backtrace: Thread no. 1 (10 frames) #2 wl_abort at src/wayland-util.c:418 #3 wl_proxy_marshal_array_constructor_versioned at src/wayland-client.c:653 #4 wl_proxy_marshal_array_constructor at src/wayland-client.c:599 #5 wl_proxy_marshal at src/wayland-client.c:696 #6 wl_data_device_start_drag at /usr/include/wayland-client-protocol.h:2551 #7 gdk_wayland_drag_context_manage_dnd at gdkdnd-wayland.c:404 #8 gtk_drag_begin_internal at gtkdnd.c:1814 #9 gtk_drag_begin_with_coordinates at gtkdnd.c:1979 #10 gtk_entry_event at gtkentry.c:4306 #11 _gtk_marshal_BOOLEAN__BOXEDv at gtkmarshalers.c:131 Full backtrace in the downstream bug, as usual.
Is drag-and-drop working for wayland? On the wayland test bot there are many crashes that seem related to that: https://build.webkit.org/results/GTK%20Linux%2064-bit%20Release%20Wayland%20%28Tests%29/r210585%20%2827%29/results.html
(In reply to comment #1) > Is drag-and-drop working for wayland? In general, yes it is. I'm sure we used to have a bug where it would just crash, but seems to work generally now. So it's good that we have layout tests that can reproduce drag-and-drop issues that might otherwise be non-obvious.
(In reply to comment #2) > (In reply to comment #1) > > Is drag-and-drop working for wayland? > > In general, yes it is. I'm sure we used to have a bug where it would just > crash, but seems to work generally now. So it's good that we have layout > tests that can reproduce drag-and-drop issues that might otherwise be > non-obvious. Can you reproduce the crashes on those tests by running them with --display-server=wayland and without using the internal jhbuild? The bot is running with gtk+ 3.16 and wayland/weston 1.8. I wonder if the issue is also reproducible on last fedora.
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > Is drag-and-drop working for wayland? > > > > In general, yes it is. I'm sure we used to have a bug where it would just > > crash, but seems to work generally now. So it's good that we have layout > > tests that can reproduce drag-and-drop issues that might otherwise be > > non-obvious. > > Can you reproduce the crashes on those tests by running them with > --display-server=wayland and without using the internal jhbuild? Hm, I'm not sure I want to try figuring out how to run layout tests outside the internal jhbuild. I tried this: $ jhbuild run run-webkit-tests --gtk --build-directory=/home/mcatanzaro/Projects/WebKit/WebKitBuild/GNOME editing/pasteboard ('jhbuild run' is necessary because I always build WebKit inside my GNOME JHBuild environment.) I got this error: WebKitTestRunner was not found at /home/mcatanzaro/Projects/WebKit/WebKitBuild/GNOME/Release/bin/WebKitTestRunner The problem is that it appended /Release to the build directory. I need it to not do that. :/ > The bot is running with gtk+ 3.16 and wayland/weston 1.8. I wonder if the > issue is also reproducible on last fedora. Ah, good point. That's an eternity in Wayland years. ;) I don't think the results from our Wayland bot will be very useful until upgrade our JHBuild environment to GTK+ 3.22. I still insist on getting the bots green before we do that. I will try to work on this in April if nobody beats me to it.
(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > (In reply to comment #1) > > > > Is drag-and-drop working for wayland? > > > > > > In general, yes it is. I'm sure we used to have a bug where it would just > > > crash, but seems to work generally now. So it's good that we have layout > > > tests that can reproduce drag-and-drop issues that might otherwise be > > > non-obvious. > > > > Can you reproduce the crashes on those tests by running them with > > --display-server=wayland and without using the internal jhbuild? > > Hm, I'm not sure I want to try figuring out how to run layout tests outside > the internal jhbuild. I tried this: > > $ jhbuild run run-webkit-tests --gtk > --build-directory=/home/mcatanzaro/Projects/WebKit/WebKitBuild/GNOME > editing/pasteboard > > ('jhbuild run' is necessary because I always build WebKit inside my GNOME > JHBuild environment.) > > I got this error: > > WebKitTestRunner was not found at > /home/mcatanzaro/Projects/WebKit/WebKitBuild/GNOME/Release/bin/ > WebKitTestRunner > > The problem is that it appended /Release to the build directory. I need it > to not do that. :/ > I do the following: #1 Rename your current build dir to restore it later: $ mv WebKitBuild WebKitBuild.back #2 Build webkit without support for media-stream because it requires openwebrtc that is not shipped with your distro. $ Tools/Scripts/build-webkit --gtk --release --cmakeargs='-DENABLE_MEDIA_STREAM=OFF' #3 When it finish, run the layout tests as usual using the script Tools/Scripts/run-webkit-tests #4 When you finish remove this WebKitBuild directory and rename back the previous one. # Tip: using ccache helps a lot to have lower build times when doing things like this repeatedly. > > The bot is running with gtk+ 3.16 and wayland/weston 1.8. I wonder if the > > issue is also reproducible on last fedora. > > Ah, good point. That's an eternity in Wayland years. ;) I don't think the > results from our Wayland bot will be very useful until upgrade our JHBuild > environment to GTK+ 3.22. I still insist on getting the bots green before we > do that. I will try to work on this in April if nobody beats me to it.
I ran the editing/pasteboard tests. 1 passed, 302 crashed. So yeah, that's a problem. It's hard to get a backtrace due to an SELinux bug that breaks coredumpctl. :(
Many things have been fixed in both wayland and gtk in the last years. I think we will get better results in wayland bot by using much newer versions of both.
(In reply to comment #6) > I ran the editing/pasteboard tests. 1 passed, 302 crashed. So yeah, that's a > problem. > > It's hard to get a backtrace due to an SELinux bug that breaks coredumpctl. > :( Can you please mark those 302 tests as crashing on the gtk-wayland test expectations file <LayoutTests/platform/gtk-wayland/TestExpectations> with a reference to this bug, and upload it as a gardening commit? Thanks!
(In reply to comment #7) > Many things have been fixed in both wayland and gtk in the last years. I > think we will get better results in wayland bot by using much newer versions > of both. I just tested on F25 yesterday, they're all crashing. (In reply to comment #8) > Can you please mark those 302 tests as crashing on the gtk-wayland test > expectations file <LayoutTests/platform/gtk-wayland/TestExpectations> with a > reference to this bug, and upload it as a gardening commit? Are you sure they are crashing in gdk_wayland_drag_context_manage_dnd? I was unable to obtain a backtrace.
(In reply to comment #9) > (In reply to comment #7) > > Many things have been fixed in both wayland and gtk in the last years. I > > think we will get better results in wayland bot by using much newer versions > > of both. > > I just tested on F25 yesterday, they're all crashing. > > (In reply to comment #8) > > Can you please mark those 302 tests as crashing on the gtk-wayland test > > expectations file <LayoutTests/platform/gtk-wayland/TestExpectations> with a > > reference to this bug, and upload it as a gardening commit? > > Are you sure they are crashing in gdk_wayland_drag_context_manage_dnd? I was > unable to obtain a backtrace. No. I'm not sure. So maybe instead of doing that.. maybe is more correct to open a new bug with title "[GTK] 302 crashes on editing/pasteboard with Wayland" and assign all the bugs to this one, and make this one related to it?