I am integrating form interactions and have registered the FFI_SetCursor callback in FPDF_FORMFILLINFO. However, when I move the mouse and call FORM_OnMouseMove over a widget of type /FT /Btn (e.g., checkbox or button), my registered FFI_SetCursor callback is never triggered.
After debugging the PDFium source, I found that inside the function:
bool CFFL_InteractiveFormFiller::OnMouseMove(
CPDFSDK_PageView* pPageView,
ObservedPtr<CPDFSDK_Widget>& pWidget,
Mask<FWL_EVENTFLAG> nFlags,
const CFX_PointF& point) {
CFFL_FormField* pFormField = GetOrCreateFormField(pWidget.Get());
return pFormField && pFormField->OnMouseMove(pPageView, nFlags, point);
}
the pFormField object is actually of type CFFL_CheckBox, which inherits from CFFL_Button, which in turn inherits from CFFL_FormField. Notably, CFFL_FormField has a declared and defined virtual method OnMouseMove, but CFFL_Button overrides it with this implementation:
bool CFFL_Button::OnMouseMove(CPDFSDK_PageView* pPageView,
Mask<FWL_EVENTFLAG> nFlags,
const CFX_PointF& point) {
return true;
}
This empty override effectively blocks the base class logic that would presumably trigger FFI_SetCursor.
Is this behavior an intentional design choice in PDFium? Or is it a bug that FFI_SetCursor is not triggered for button-like widgets on mouse move?
Also, what is the intended usage of FFI_SetCursor? Must the UI layer itself traverse all annotations/widgets and decide which cursor to show based on the widget /FT type?
Thanks in advance for any clarifications!