Bug description
In CEF OSR mode, (custom) cursors are passed to the host application via "CefDisplayHandler::OnCursorChange".
The call comes from "cursor_util::OnCursorChange", where before being passed out, the cursor is put into a ScopedCursorHandle.
The "naked" cursor handle is passed out to the host, so there is no chance for participation in ref-counting or similar.
This leaves the host application with a handle that directly after "CefDisplayHandler::OnCursorChange" becomes invalid.
If the application sets the windows application Cursor e.g. via "SetCursor", the cursor changes but afterwards, the OS seems to also have a "dangling reference" to the cursor. This can be observed with calling "GetCursorInfo", which returns an error in this situation.
Applications like Barco ClickShare which use "GetCursorInfo" to get and transmit the cursor this way cannot capture and therefore not display the cursor shape on the remote display.
For system cursors, the problem does not surface as those standard cursor handles cannot be deleted and stay valid.
To Reproduce
Start cefclient in OSR mode
Browse to a html page that uses custom cursors
In another application, repeatedly call "GetCursorInfo"
See call failing with a windows error code
Expected behavior
Expectation would be that one can either take ownership of the returned cursor handle or participate in shared ownership. The workaround is to clone the cursor in the callback, which is not very nice.
Versions (please complete the following information):
OS: Win 11
CEF Version: 126.2.9
Chromium Version: 126.0.6478.127
Additional context
The problem can be reproduce with the cefclient application.
Bug description In CEF OSR mode, (custom) cursors are passed to the host application via "CefDisplayHandler::OnCursorChange". The call comes from "cursor_util::OnCursorChange", where before being passed out, the cursor is put into a ScopedCursorHandle. The "naked" cursor handle is passed out to the host, so there is no chance for participation in ref-counting or similar.
This leaves the host application with a handle that directly after "CefDisplayHandler::OnCursorChange" becomes invalid.
If the application sets the windows application Cursor e.g. via "SetCursor", the cursor changes but afterwards, the OS seems to also have a "dangling reference" to the cursor. This can be observed with calling "GetCursorInfo", which returns an error in this situation.
Applications like Barco ClickShare which use "GetCursorInfo" to get and transmit the cursor this way cannot capture and therefore not display the cursor shape on the remote display.
For system cursors, the problem does not surface as those standard cursor handles cannot be deleted and stay valid.
To Reproduce
Expected behavior Expectation would be that one can either take ownership of the returned cursor handle or participate in shared ownership. The workaround is to clone the cursor in the callback, which is not very nice.
Versions (please complete the following information):
Additional context The problem can be reproduce with the cefclient application.