Opened 4 years ago

Last modified 15 months ago

#12267 confirmed defect

Strange focus events in wxOSX/Cocoa

Reported by: mikk Owned by:
Priority: low Milestone:
Component: wxOSX-Cocoa Version: stable-latest
Keywords: focus Cc:
Blocked By: Blocking:
Patch: no


Use the following configure options to build the library and grid sample

configure --disable-shared --with-osx_cocoa --with-osx-min-version=10.5 --enable-monolithic

Run the grid sample, and click in cell A1. The editor does not become active like it should. If you then move the mouse, the program will hang.

If you use the following configure options

configure --disabled-shared --with-osx_carbon --with-osx-min-version=10.5 --enable-monolithic

the grid sample works as expected.

Attachments (1)

CocoaGridFocus.patch download (714 bytes) - added by mikk 4 years ago.

Download all attachments as: .zip

Change History (9)

comment:1 Changed 4 years ago by vadz

Could you please run it under debugger, break into it when it hangs and see what is going on?

comment:2 Changed 4 years ago by mikk

  • Patch set

The code gets stuck in an infinite loop. The SetFocus called from wxGridCellTextEditor::DoBeginEdit recurses. I have added code similar to revision 58969 to avoid the recursion.

Changed 4 years ago by mikk

comment:3 Changed 4 years ago by vadz

  • Priority changed from high to critical
  • Status changed from new to confirmed

"Something similar" was actually done in r34609 (which, unlike r58969, wasn't done by me) and I think it was a rather bad idea to do it like this. The dynamic cast is ugly and the problem is, of course, the completely unexpected kill focus event: why is it generated for the text control that we're setting the focus to?

This looks like a wxOSX/Cocoa bug and I think it would be much better to fix it instead of adding workarounds for it. I don't know why is wxOSX_resignFirstReponder called by the system (gdb shows it being called from [NSWindow makeFirstResponser:] called by NSScrollView becomeFirstResponder] which is used by SetFocus()) but if this is unavoidable I think we should filter out these unwanted events at wx level.

Of course, the problem "fixed" by r34609 was mostly likely a bug in wxMSW as well... (which I hope is fixed by now so I'll try to retest whether we can simply remove this code).

comment:4 Changed 4 years ago by vadz

  • Keywords focus added; wxGrid removed
  • Patch unset
  • Priority changed from critical to low
  • Summary changed from Grid sample hangs on OSX Cocoa 64-bit to Strange focus events in wxOSX/Cocoa

I really don't know what's going on here, after spending another half an hour of debugging this I still have no idea why is wxEVT_KILL_FOCUS event generated from inside wxWindow::SetFocus() has both the window receiving focus and the one losing it as one and the same (wxGridWindow). It seems clear that this shouldn't happen and filtering out such events seems to solve the problem without, hopefully, introducing any other ones, but I think there is still something fundamentally wrong here. Stefan, could you please have a look at this if you have some time? I'm confused/lost.

I'm changing the bug priority as the crash will be fixed when I commit my changes but I leave it opened because of the above.

comment:5 Changed 4 years ago by VZ

(In [65382]) Work around a crash on starting editing in wxGrid under wxOSX/Cocoa.

wxOSX/Cocoa currently generates unexpected focus loss events with the window
gaining focus being the same one as losing it. This is wrong and shouldn't
happen but as long as it does, filter these events out to at least allow
editing the grid to work.

See #12267.

comment:6 Changed 15 months ago by csomor

r65382 leads to a suppression of the focus kill for the stc

comment:7 Changed 15 months ago by csomor

see #14938

comment:8 Changed 15 months ago by SC

(In [73967]) deactivating r65382 see #12267 (which does not seem to happen anymore even without this change), fixes #14938,

Note: See TracTickets for help on using tickets.