WebView on Linux when linking QtWebEngine: Some position related operation breaks after host window move.

[HITOA]

Hi, I noticed an issue with dpf's webview about window position.

Some position related operation like drag & drop, and opening the context menu of the webview, start to break after moving the window.
This is immediatelly fixed after a resize, which seems to update whatever value was cached by the webview that wasn't updated by simply moving the window. I took a screenshoot to hopefully make the issue more understandable, The red dot is the position of the mouse, I can't screenshot my own mouse with my current setup;

Notice the offset between the mouse position when the right click was triggered and the position of the context menu. The offset between the two is exactly the offset between the current position and the last window position after resizing. The issue is the same with drag & drop. The rect for the drag zone is not updated correctly. which in my case is my main issue.

The fix seems to be about notifying the webview when the window position change. Calling webViewResize also seems to update whatever needed to be. I don't know if this bug happens on windows or mac, or even with Webkit GTK.

I'm on Linux, NixOS with wayland, The plugin should run with XWayland tho cause there doesn't seem to have any implementation of dpf webview for wayland anyway. the plugin is linking at runtime to QtWebEngine libQt6WebEngineWidgets.so.

[falkTX]

This is already fixed in develop branch, did you try?

[HITOA]

I just tried and pulled the last change on develop, yes sadly the issue still remain on my side even after a full clean build in case something was cached. Actually there is one more issue now the context menu doesn't even show up. It's not a big deal in my case but might be for some people.

[HITOA]

Regarding the context menu issue, I'm not sure if I should post about it here, but just in case I thought this might be usefull:

Received signal 11 SEGV_MAPERR 000000000010
#0 0x7695f8d95da5 base::debug::CollectStackTrace()
#1 0x7695f8d81e98 base::debug::StackTrace::StackTrace()
#2 0x7695f8d9624a base::debug::(anonymous namespace)::StackDumpSignalHandler()
#3 0x769601c42790 (/nix/store/57iz36553175g3178pvxjij8z5rcsd4n-glibc-2.42-61/lib/libc.so.6+0x4278f)
#4 0x7695f8c3d114 

QWebEngineContextMenuRequest::isContentEditable()
#5 0x7695f35f4810 QtWebEngineCore::RenderViewContextMenuQt::initMenu()
#6 0x7696073a8197 QWebEngineView::createStandardContextMenu()
#7 0x769602ad8786 DISTRHO::WebViewEventFilter::timerEvent()
#8 0x7695ef61f375 QObject::event()
#9 0x7695f09a8d2f QApplicationPrivate::notify_helper()
#10 0x7695ef5bb828 QCoreApplication::notifyInternal2()
#11 0x7695ef7b7969 QTimerInfoList::activateTimers()
#12 0x7695ef9129f9 timerSourceDispatch()
#13 0x7695eef00c4b g_main_context_dispatch_unlocked
#14 0x7695eef04218 g_main_context_iterate_unlocked.isra.0
#15 0x7695eef04adf g_main_context_iteration
#16 0x7695ef912d0d QEventDispatcherGlib::processEvents()
#17 0x7695ef5c99ab QEventLoop::exec()
#18 0x7695ef5c4d79 QCoreApplication::exec()
#19 0x769602acb016 DISTRHO::qtwebengine()
#20 0x769602ad51d5 DISTRHO::dpf_webview_start()
#21 0x769601c2b285 __libc_start_call_main
#22 0x769601c2b338 __libc_start_main_alias_2
#23 0x769602aa48d5 _start
  r8: 0000000000000000  r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000
 r12: 00007ffebfe2f580 r13: 00005555770d58d0 r14: 00007ffebfe2fe00 r15: 0000555577ac4b70
  di: 0000000000000000  si: 0000000000000000  bp: 00007ffebfe2f5d0  bx: 00007ffebfe2f5e0
  dx: 0000000000000000  ax: 0000000000000000  cx: 0000000000000000  sp: 00007ffebfe2f558
  ip: 00007695f8c3d114 efl: 0000000000010246 cgf: 002b000000000033 erf: 0000000000000004
 trp: 000000000000000e msk: 0000000000001000 cr2: 0000000000000010
[end of stack trace]

So this isn't just a context menu thing, it completelly crash the webview

[falkTX]

does it make any difference if it is a plugin embed in a daw vs the jack standalone?

[HITOA]

The result above was with jack standalone, as for embed, I tried VST3 inside reaper, context menu of any kind still crashes the plugin, and the position is still messed up as well.

[falkTX]

That seems odd to me, are you sure you tried develop branch?

In here the QtWebEngine does not show up the back/forward buttons, I added some code to remove those. So if you get them you are likely in an older commit.

[HITOA]

Running git show --summary show the lattest commit being Detect wrong build config at runtime for DISTRHO_UI_WEB_VIEW which i believe to be the right one ? Regarding the back/forward button, the first screen was before i pulled the last change on develop wich is why it showed them (so yeah the first screen is not on the develop branch) now tho i can't really tell if the button are present or not as the context menu doesn't appear, it crashes instead. But according to the git summary I do believe this is the right branch and the right commit. But this is odd yeah.. I'm trying to figure out a bit more but i'm not sure where to look.

[falkTX]

get a trace for the crash and I can take a look.

for deeper investigation of the qt6 webview you can setup the build alike https://github.com/falkTX/Anfima/blob/main/CMakeLists.txt#L169-L177 so that it uses real Qt instead of loading it at runtime. Makes it a lot easier to debug.

[HITOA]

Isn't the trace I sent earlier good :o? Anyway I'll try compiling with qt and see if i can debug properly thanks.

[falkTX]

Isn't the trace I sent earlier good :o? Anyway I'll try compiling with qt and see if i can debug properly thanks.

sorta, but if doing changes/tweaks to the code its not practical with the default dynamic loading enabled.

[HITOA]

Ah yeah make sense.
Ok so I compiled with QT as you linked. And the crash does not happen now regarding context menu, there is still a few weird thing like the context menu of the webview showing even with prevent default, but at least it's working. So well i can't really debug something that's isn't hapenning. Regarding the position tho, still the same issue, I'm honestly not sure where to look/how to debug that, If you want me to do/provide something specific please tell me and I'll be happy to provide what I can.

A small note on the crash not hapenning. The webengine version should be the same as i'm pulling it from the same package repository.

[falkTX]

Look into the line with:

// HACK forcing webview window position, needed for sub-menus

And see if you can find some extra thing to make it work.

Is the event filter even being called for you?

[HITOA]

Ok i'm so incredibly confused, I just relaunched the synth again and it crashes again, well at least i can debug now! Maybe some memory get corrupted ?
I believe the event filter is being called. The trace when crashing show WebViewEventFilter::timerEvent()
Thanks for the instruction I'll see what i can do.

[HITOA]

Ok so I somewhat fixed Half of the problem. I did not found the source of the crash yet, It might or might not be DPF, it looks like memory corruption but QtWebEngine (and all the child process) is giving me a real hard time to debug, I'm not really good with gdb beside the basic so it will take me a bit more time.

Regarding the positioning problem, The fix actually does work for the context menu, but the hacky solution only check for QEvent::ContextMenu, wich doesn't fix it for drag & drop event, and their might be other event that need that fix that i'm not aware of either.

That mean a possible fix might be something like this:

if (type == QEvent::DragEnter) {
    if (_winId != 0)
    {
        XWindowAttributes attrs;
        XGetWindowAttributes(_display, _winId, &attrs);
        XMoveWindow(_display, _winId, attrs.x + 1, attrs.y);
        XMoveWindow(_display, _winId, attrs.x, attrs.y);
        XFlush(_display);
    }
}

And of course adding the DragEnter event (wich is 60) to the QEvent struct.
How does that sound ?

[falkTX]

does it work with

if ((type == QEvent::ContextMenu || type == QEvent::DragEnter) && watched == reinterpret_cast<QObject*>(_view))
{
...
}

?