QOpenGLWidget crashes when created or restored on second monitor.

UPDATE - This crash only requires a QOpenGLWidget and does not appear to be isolated to the QWebEngineView as initially thought. We have updated our test application to be smaller and just contain a QOpenGLWidget as a simpler example.

We have had consistent reports from our users about crashes when our app loads on a second monitor. After a great deal of investigation it appears to be related to the QWebEngine view, specifically to do with an OpenGL swapBuffers() call in the private implementation of QWebEngine view which seems to lock the thread in QGui.dll.

To the user, the crash basically involves the app going white and unresponsive until clicked, at which point the standard Windows crash dialog appears.

It seems to lock up in qopenglcontext.cpp on line 1120 (in 5.15.2 branch), and this is called from qplatformbackingstore.cpp on line 480 (in 5.15.2 branch)

    d->platformGLContext->swapBuffers(surfaceHandle);

in the QOpenGLContext::swapBuffers(QSurface *surface) method (which is called from QPlatformBackingStore::composeAndFlush(...) ).

The frustrating thing is that it's only certain systems that crash and they can be running Intel, AMD or Nvidia GPUs. The only thing that is consistent is that the app is opening on a second monitor. It can be opened on the first monitor and dragged over, but will lock up the next time it launches with restoreGeometry().

We have created a simple bare-bones Qt project with an empty QOpenGLWidget that will crash on startup when restored on the second monitor on these systems.

General process (on systems where the crash is reproduced):
1. Run the minimal app.
2. Move the app to the second monitor.
3. Close the app.
4. Open the app again (restoring itself to the second monitor).

Expected:
5. App opens on second monitor, blank (black) QOpenGLWidget appears.
Actual:
5. App appears on second monitor, window goes white and unresponsive until clicked. At which point the Windows process crash dialog will appear.

Appendum: We have included a Qt Project (glwidgetcrash.zip), but for our own testing we have also converted it to Visual Studio Qt Solution so that we can use Visual Studio's remote debugging functionality on machines that exhibit this GLSwapBuffers lock up behaviour.