On Mon Oct 27 09:38:46 2025 +0000, Byeongsik Jeon wrote:
The waitUntilQueryDone method waits for the execution of query_ime_char_rect and eventually reaches a timeout. By OnMainThread:
-[WineContentView firstRectForCharacterRange:actualRange:] -[WineApplicationController waitUntilQueryDone:timeout:processEvents:] *done=0 -[WineContentView setMarkedText:selectedRange:replacementRange:] -[WineContentView firstRectForCharacterRange:actualRange:] -[WineApplicationController waitUntilQueryDone:timeout:processEvents:] *done=0By macdrv_ProcessEvents:
0024:trace:ime:query_ime_char_rect win 0x10118/0x7fcbe6144260 himc 0x1011e range 0-0 0024:trace:ime:query_ime_char_rect -> range 0-0 rect (134,442)-(137,481) 0024:trace:ime:macdrv_im_set_text win 0x10118/0x7fcbe6144260 himc 0x1011e text L"n" complete 0 0024:trace:ime:query_ime_char_rect win 0x10118/0x7fcbe6144260 himc 0x1011e range 0-1 0024:trace:ime:query_ime_char_rect -> range 0-1 rect (134,442)-(137,481)Without the WineQueryNoPreemptWait flag, it executes as follows:
-[WineContentView firstRectForCharacterRange:actualRange:] 0024:trace:ime:query_ime_char_rect win 0x10118/0x7fcbe6144260 himc 0x1011e range 0-0 0024:trace:ime:query_ime_char_rect -> range 0-0 rect (134,442)-(137,481) -[WineApplicationController waitUntilQueryDone:timeout:processEvents:] *done=1
Interesting, I still believe that this sometimes deadlock (with a luckily .3s timeout) with the Japanese IME, is not a regression caused by this commit per se, just exasperated by making `macdrv_ImeProcessKey` faster.
I think we could get rid of the original race described in https://gitlab.winehq.org/wine/wine/-/commit/33610da6b4f5d9ad052173f005fdb73... by getting rid of IM_SET_TEXT and then effectively reverting that commit, removing this deadlock.
I'll poke at this again later today; thanks for the review, testing and insight so far!