ContextMenuParams are unusable in ContextMenuHandler

[cybersight]

I'm trying to use the context menu callbacks with offscreen rendering and am having issues trying to to customize the context menu.

The ContextMenuParams and MenuModel structs being sent to the OnBeforeContextMenu callback are somehow broken, in that getter methods always return 0, and methods for modifying the menu have no effect. In comparison, the Browser and Frame objects being sent to the same callback work perfectly fine. Same is true for the RunContextMenu callback.

For example, params.get_xcoord() and params.get_ycoord() always return 0, as well as params.is_editable() even when a text input field is selected. Also, model.clear() always returns 0, indicating failure.

The context menu widget works fine, in that it displays in the correct location, and the default actions work correctly. Even returning 1 from RunContextMenu has the expected behavior in that the context menu gets suppressed. But I can't read or write to any of the structs that define it.

Full context, I'm using Windows 32-bit build in Dolphin Smalltalk, with offscreen rendering, and multithreaded message loop enabled. The language bindings use the C API, and the FFI for ContextMenuParams structs is defined here: https://github.com/JBetz/Dolphin-CEF/blob/master/Chromium%20Embedded%20Framework/CefContextMenuParams.cls#L519-L586

I've never run into this failure state before so I don't think it's a platform issue. My best guess is that it has something to do with which thread the context menu was created on, but I don't know how to test this theory.

[magreenblatt]

You should probably start by reporting the issue to the Dolphin CEF project maintainers.

[cybersight]

You should probably start by reporting the issue to the Dolphin CEF project maintainers.

I'm the sole maintainer. :}

I've implemented multiple other handlers (display, focus, keyboard, lifespan, render, request), as well as other structs with method fields, and haven't had this problem. So I'm at my wits' end for how to debug it.

[cybersight]

I just tested with windowed rendering and it has the same issue, so doesn't seem to be connected to OSR.

[magreenblatt]

Are you able to step into native code from your Dolphin Smalltalk binary? That would probably be the best/easiest way to debug this.

[magreenblatt]

I'm the sole maintainer. :}

Welcome to CEF development land

[cybersight]

Are you able to step into native code from your Dolphin Smalltalk binary? That would probably be the best/easiest way to debug this.

It should be possible to hook up Dolphin's VM to a C++ debugger and then set breakpoints in the FFI code, since the VM is also written in C++. But would be painful. And there isn't a way to go directly from Smalltalk to C++. I'm also not sure how the fact I'm using the C API and not C++ would affect things.

I'm the sole maintainer. :}

Welcome to CEF development land

Lol, thanks

[cybersight]

Okay, I was able to get context menus working after making two changes:

1. Calling `release()` on CefContextMenuParams and CefMenuModel arguments passed to the callback handlers.
2. Switching from a multi-threaded message loop to an integrated message loop using CefDoMessageLoopWork.

The second was unexpected even if sort of makes sense if the context menu gets created on the UI thread. But if that's the case, shouldn't there be a warning in the documentation that multi_threaded_message_loop is incompatible with the context menu handler?

Side note: What enabled me to debug the callbacks was finding log messages like "Check failed: paramsPtr->HasOneRef()" and "Check failed: false. called on invalid thread" in the CEF log. I don't remember seeing those before, but perhaps I wasn't using a debug build of CEF.

[magreenblatt]

shouldn't there be a warning in the documentation that multi_threaded_message_loop is incompatible with the context menu handler?

I don't think it's generally incompatible. You may be hitting a CEF/Chromium bug, or some incompatibility specific to your application. I suggest testing with "cefclient --multi-threaded-message-loop" to understand the expected (possibly CEF/Chromium buggy) behavior.

[cybersight]

shouldn't there be a warning in the documentation that multi_threaded_message_loop is incompatible with the context menu handler?

I don't think it's generally incompatible. You may be hitting a CEF/Chromium bug, or some incompatibility specific to your application. I suggest testing with "cefclient --multi-threaded-message-loop" to understand the expected (possibly CEF/Chromium buggy) behavior.

If I use cefclient.exe as the browser subprocess with multi-threaded message loop enabled, context menus have the same behavior as I described in the original post.

If I just run ".\cefclient.exe --multi-threaded-message-loop" from a Powershell, the browser is definitely able to customize the context menus because they have a lot more in them than the defaults I'm used to seeing in my app.

So I think you're right and it is an issue with multi-threading in my app and/or platform.