wxWindow::SetCursor() has no lasting effect on a child window under macOS. This came up in #27059, where the hand cursor of the native wxHyperlinkCtrl was never shown, but it is not specific to that control: a wxStaticText with wxCURSOR_HAND inside a wxPanel has the same problem.
Cursor update and mouse enter events are sent to every window containing the mouse and not only to the deepest one, so the parent calls MacSetupCursor() too and, as it runs after the child, its cursor wins. wxWidgetCocoaImpl::mouseEvent() already ignores mouse moved events for the windows which are not under the mouse, so this does the same in SetupCursor(), for all events, by walking up from the view under the mouse to the first one belonging to a wx window.
Checked with a test program which moves the mouse using CGEventPost() and then reads back [NSCursor currentCursor]:
| control | before | after |
|---|---|---|
| wxStaticText with wxCURSOR_HAND in a panel | arrow | hand |
| native wxHyperlinkCtrl from #27059 | arrow | hand |
| sibling window with no cursor of its own | arrow | arrow |
| wxTextCtrl | IBeam | IBeam |
The last two rows are there because the cursor must still be reset when the mouse leaves the child, and because the I-beam of the text control comes from AppKit's own cursor rects and had to keep working.
https://github.com/wxWidgets/wxWidgets/pull/27091
(2 files)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
@csomor is right and my first description was wrong, sorry. I have redone the measurement, this time moving the mouse in small steps instead of jumping it from one point to another in a single event:
| control | without: glide / jump | with: glide / jump |
|---|---|---|
| wxStaticText with wxCURSOR_HAND | hand / arrow | hand / hand |
| native wxHyperlinkCtrl (#27059) | hand / arrow | hand / hand |
| sibling with no cursor of its own | arrow / arrow | arrow / arrow |
| wxTextCtrl | IBeam / arrow | IBeam / IBeam |
So normal mouse movement was already correct: the child keeps getting mouse moved events, and mouseEvent() already hit tests those, so the child's cursor wins. What my first test really hit is the case where the pointer arrives in the child in a single event, i.e. when it is warped rather than moved. The only events are then mouseEntered for the child and mouseExited for the parent, the parent runs last, and its cursor is used. The same happens to the I-beam of a wxTextCtrl, as the last row shows.
That is much narrower than what I claimed. It still looks wrong to me, and it affects wxUIActionSimulator::MouseMove(), which warps the pointer, as well as assistive software doing the same, but it is not the everyday problem I made it out to be. Your call whether it is worth changing, and I am happy to close this if you would rather leave the current behaviour alone. I have updated the description with the corrected numbers.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
@vadz commented on this pull request.
@csomor Could you please have a look at this small diff if possible? I don't know if it really needs to be done, as the comment claims, or not.
In docs/changes.txt:
> @@ -357,6 +357,7 @@ wxMSW: wxOSX: - Fix dataview icons rendering under macOS 26 (#26374). +- Fix wxWindow::SetCursor() being overridden by the parent window.
Please tell your LLM/agent to remember to avoid modifying this file, see the instructions for updating it above.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
@trypsynth commented on this pull request.
In docs/changes.txt:
> @@ -357,6 +357,7 @@ wxMSW: wxOSX: - Fix dataview icons rendering under macOS 26 (#26374). +- Fix wxWindow::SetCursor() being overridden by the parent window.
Thanks, will do, and I'll be sure to add no changelog entries to my pre-submition review checklist too :)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
@csomor Could you please have a look at this small diff if possible? I don't know if it really needs to be done, as the comment claims, or not.
As the problem only happens in non-regular situations, when warping pointers, ie assistive devices or UI testing, we are not really under pressure IMHO. I've tested nested panels where cursor events are skipped from the inner panel, but couldn't trigger a regression. So from a risk standpoint I think we can apply it, but I'd prefer postponing it after the 3.3.4 release.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
Also not sure about this one. On one hand, the change makes sense but OTOH I don't understand why should the behaviour be different with and without "jump". Maybe WarpPointer() needs to do something to update the cursor instead?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()
@vadz I think it's fine to merge into master now, as @trypsynth wrote, also assistive technologies may do this, so let's see whether we run into a regression in ordinary use
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you are subscribed to this thread.![]()