Description of problem:
During initial setup, I clicked on google online account that become gray, then the window suddenly close.
Version-Release number of selected component:
cmdline: /usr/libexec/gnome-initial-setup --existing-user
runlevel: N 5
Thread no. 1 (10 frames)
#0 webkitWebViewBaseMakeGLContextCurrent at /usr/include/c++/9/bits/unique_ptr.h:357
#1 WebKit::WebPageProxy::makeGLContextCurrent at ../Source/WebKit/UIProcess/gtk/WebPageProxyGtk.cpp:161
#2 WebKit::WaylandCompositor::Surface::setWebPage at ../Source/WebKit/UIProcess/gtk/WaylandCompositor.cpp:176
#3 WebKit::WaylandCompositor::unregisterWebPage at ../Source/WebKit/UIProcess/gtk/WaylandCompositor.cpp:574
#4 WebKit::AcceleratedBackingStoreWayland::~AcceleratedBackingStoreWayland at ../Source/WebKit/UIProcess/gtk/AcceleratedBackingStoreWayland.cpp:144
#6 std::default_delete<WebKit::AcceleratedBackingStore>::operator() at /usr/include/c++/9/bits/unique_ptr.h:75
#7 std::unique_ptr<WebKit::AcceleratedBackingStore, std::default_delete<WebKit::AcceleratedBackingStore> >::reset at /usr/include/c++/9/bits/unique_ptr.h:399
#8 std::unique_ptr<WebKit::AcceleratedBackingStore, std::default_delete<WebKit::AcceleratedBackingStore> >::operator=(decltype(nullptr)) at /usr/include/c++/9/bits/unique_ptr.h:333
#9 webkitWebViewBaseDispose at ../Source/WebKit/UIProcess/API/gtk/WebKitWebViewBase.cpp:553
#11 gtk_overlay_forall at gtkoverlay.c:628
Created attachment 1613109 [details]
Created attachment 1613110 [details]
Created attachment 1613111 [details]
Created attachment 1613112 [details]
Created attachment 1613113 [details]
Created attachment 1613114 [details]
Created attachment 1613115 [details]
Created attachment 1613116 [details]
Created attachment 1613117 [details]
Created attachment 1613118 [details]
Created attachment 1613119 [details]
This is strange.
In a VM it works.
On baremetal I encounter this issue.
Each time that on initial setup I try to set up a google account, the window where I should put my credentials become gray.
If I close such window, initial setup crashes.
Note: the same thing happens as well on gnome-control-center. So the problem could not be related to gnome-initial-setup.
Similar problem has been detected:
Gnome-initial-setup crashes when Google or Microsoft account dialog is opened. The window is completely blank, and once you try to close it, the whole g-i-s crashes and you only have an empty screen (you can still reboot the system from the upper right corner, then g-i-s runs again). This only happens on bare metal or a VM with 3D acceleration (gnome-boxes by default, virt-manager if you enable it), on a VM without 3d acceleration everything works fine.
reason: gnome-initial-setup killed by SIGSEGV
runlevel: N 5
Created attachment 1614865 [details]
video bug demonstration
I can confirm this also happens when adding Online Accounts in Settings.
I propose this as F31 Final blocker, due to following criteria:
"All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use. "
"A working mechanism to create a user account must be clearly presented during installation and/or first boot of the installed system."
You can't add certain accounts (Google, Microsoft, perhaps more) in online accounts on systems with 3D hardware acceleration (bare metal, boxes, virt-manager with 3D acceleration enabled). The gnome-initial-setup crashes if you try to do so and fails to create a user account (of course, you can reboot and avoid the crashing dialog, that works fine).
(In reply to Kamil Páral from comment #15)
> You can't add certain accounts (Google, Microsoft, perhaps more) in online
So 3D acceleration is the reason why on a KVM machine I didn't spotted the issue, while I can't create online accounts on baremetal as reported on comment 12, right?
(In reply to Alessio from comment #16)
> So 3D acceleration is the reason why on a KVM machine I didn't spotted the
> issue, while I can't create online accounts on baremetal as reported on
> comment 12, right?
Very likely. If you use virt-manager, configure your VM to use virtio video (3d acceleration enabled) and spice display (OpenGL enabled, Listen Type: None) and you should see the crashes even in your VM. That's how I reported this (and also verified the bare metal crashes yesterday). Or use gnome-boxes with default options and it should behave the same way.
(In reply to Kamil Páral from comment #17)
> Very likely. If you use virt-manager, configure your VM to use virtio video
> (3d acceleration enabled) and spice display (OpenGL enabled, Listen Type:
I can confirm that. Enabling 3D Acceleration it crashes. Otherwise, with 3D acceleration disable, it works.
See also bug 1749709
Is that a duplicate of this one? Or vice versa :-)
*** Bug 1749709 has been marked as a duplicate of this bug. ***
BTW I think you should report a second bug for the view not rendering. This bug will be resolved when the crash is fixed, but that's not going to do anything to make it display stuff.
(In reply to Michael Catanzaro from comment #21)
> BTW I think you should report a second bug for the view not rendering. This
> bug will be resolved when the crash is fixed, but that's not going to do
> anything to make it display stuff.
Good idea, already reported as bug 1751936.
(In reply to Kamil Páral from comment #22)
> Good idea, already reported as bug 1751936.
Also: bug #1748817.
Discussed during the 2019-09-16 blocker review meeting: 
The decision to classify this bug as an "AcceptedBlocker" was made as it violates the following criterion:
"All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use"
There is a fix to this bug already - https://trac.webkit.org/changeset/249947/webkit. The other issue - bug 1751936 is probably caused by mesa - at least according to https://bugs.webkit.org/show_bug.cgi?id=200856#c18
FEDORA-2019-fef2eda60a has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-fef2eda60a
webkit2gtk3-2.26.0-2.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-fef2eda60a
The update works here.
webkit2gtk3-2.26.0-2.fc31 fixes the issue.
webkit2gtk3-2.26.0-2.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.