https://bugs.documentfoundation.org/show_bug.cgi?id=168970
--- Comment #3 from Neil Roberts <[email protected]> --- It looks like the focus handling on the GTK3 backend is a bit buggy and that’s why the table controls never get the lost focus event when GrabFocus() is called. With that backend ImplGetSVData()->mpWinData->mpFocusWin is always null so when GrabFocus is called it doesn’t know who to send the event to. It also doesn’t keep track of whether a toplevel window is focused so WindowImpl->mbFrameData->mbHasFocus is always false for all frames. That makes GrabFocus bail out early and just raise the window to the top instead of changing the focus. I think the backend is meant to set mbFrameData->mbHasFocus by sending SalEvent::GetFocus when the frame gets focus. It looks like there is code to handle this (see the bottom of GtkSalFrame::signalFocus) but it’s tracking the keyboard focus instead of the toplevel window focus. I think it doesn’t work because the widget for the toplevel window never gets the keyboard focus itself so the code always thinks another window has the focus and only sends SalEvent::LoseFocus. I think this should be implemented by tracking the GDK_WINDOW_STATE_FOCUS state instead because that directly corresponds to the toplevel window focus. On the MacOS backend the event is sent in response to the [windowDidBecomeKey] message which I think is the equivalent of GDK_WINDOW_STATE_FOCUS. On the GTK4 backend the toplevel window focus also seems to use the keyboard focus to track the window focus, but I think it ends up working because the keyboard focus events bubble up to the toplevel window widget. If any child widget has the keyboard focus then it will end up considering the window to have focus as well. It would probably be more robust to track GDK_TOPLEVEL_STATE_FOCUS instead though. For ImplGetSVData()->mpWinData->mpFocusWin, on the MacOS backend it looks like this gets set by the controls themselves by calling GrabFocus in response to mouse click events. On the GTK backend, the controls are directly created with GtkBuilder so as far as I can tell it doesn’t actually construct an Edit::Edit control so nothing registers to listen for the mouse clicks and nothing calls GrabFocus. My preferred option so far then is to try to add a more explicit way to make OFieldDescControl flush its input instead of relying on only the focus leave events seeing as they don’t seem very reliable. -- You are receiving this mail because: You are the assignee for the bug.
