Sogou long-phrase commit fails after reparenting a sandboxed Win32 window into an external host

Describe what you noticed and did

No customer data, phrase content, account data, clipboard contents, usernames, machine paths, raw memory, or process dumps are included.

Environment

• Windows 64-bit, version 10.0.22631 / build 22631.
• Installed SbieDll.dll file version 5.72.9; SbieDrv.sys file version 5.72.8. These are observed file versions, not a conclusion that the installation is mismatched.
• SogouPY.ime x64, file/product version 16.6.0.4777.
• Disposable standard Win32 multiline EDIT in a separate process, in an empty Sandboxie box without shop logins. External parent is another Win32 process.
• Both fixture windows were observed as per-monitor aware at 96 DPI.

Reported behavior

1. Launch a fresh standalone EDIT fixture in the empty box.
2. Select an existing Sogou long custom phrase using a number key. Confirm that the complete phrase is inserted before doing any embedding.
3. Reparent the fixture window into a viewport in a process outside the box, performing the normal top-level-to-WS_CHILD style transition.
4. Focus the EDIT and select the same phrase. In the recorded failure, the candidate closes but no text is inserted. Short text can still work.
5. Releasing the child back to a standalone window has not reliably restored long-phrase insertion in that same process.

The private phrase in the existing test is 264 characters. Its content is not included. A shareable neutral replacement phrase and a standalone source-only reproducer have NOT yet been validated; please do not describe this report as a ready-to-run reproduction package.

Observed controls and limits

• A native Win32 parent without a Tk interpreter also reproduced the failure.
• A parent inside the SAME empty box allowed direct long-phrase commits by keyboard and mouse and one release/re-embed cycle. This is a limited control, not a production solution or endurance test.
• Our parent message loop did not receive keyboard-category messages during one failing commit. A separate positive control confirmed its counter worked.
• Some fresh independent fixtures also failed on their FIRST phrase attempt and then succeeded. Those instances were excluded from embedding comparisons. The initialization/measurement confound is unresolved.
• A latest plain EDIT control, stock engine, no diagnostic module or subclass, succeeded on its first long-phrase commit. Other applications were running during this control, so it is not a matched proof of diagnostic interference.

Additional experimental evidence — not stock behavior

A locally compiled, temporary v1.17.9 test DLL was used only with our own empty fixtures. All normal installations were restored after the runs. No driver, box permissions, input method settings or official client files were changed.

• Stock-path tracing showed Gui_SendInput rejecting the external foreground parent at Gui_IsSameBox (0/4 accepted).
• A strictly fixture-only experimental gate then validated that the real focus belonged to the caller's own embedded EDIT and allowed the original system SendInput call. The call accepted 4/4, but there was still no WM_PASTE or edit change. This gate was NOT retained in the installed engine and is NOT proposed as a safe general sandbox policy.
• The successful independent sample observed five keyboard-category messages reaching the EDIT queue; a failing embedded sample observed one. No key values or INPUT payloads were recorded, so the counters do not identify individual synthetic events or prove where they were consumed.
• Normal-IAT observation of Sogou's GetMessageW/PeekMessageW and CallNextHookEx did not cover the relevant route conclusively. Zero counters are not proof that internal hooks or nested message processing are absent.

Questions for maintainers

Is cross-process reparenting from a sandbox into an external parent supported for IME-generated input? Are there known restrictions involving the attached input queues, UI isolation, or an IME's own hooks that explain the stock rejection and the later accepted-but-not-delivered behavior? What minimal diagnostic would distinguish these without weakening isolation or adding a global keyboard hook?

No workaround involving automatic paste, repeated forced focus, or restarting the client is being treated as a fix.

How often did you encounter it so far?

Repeated embedding failures; exact frequency not quantified. See controls above.

Expected behavior

The complete phrase should be inserted into the focused EDIT after embedding if cross-sandbox reparenting is supported; otherwise please clarify the supported boundary.

Affected program

SogouPY.ime x64 16.6.0.4777 with a disposable Win32 EDIT fixture

Download link

Not available: standalone shareable reproducer not yet validated.

Where is the program located?

The program is installed only outside the sandbox.

Did the program or any related process close unexpectedly?

No, not at all.

Crash dump

No response

What version of Sandboxie are you running now?

SbieDll.dll 5.72.9; SbieDrv.sys 5.72.8 (observed installed file versions). Experimental DLL identified separately in description.

Is it a new installation of Sandboxie?

I have been using the same version for some time.

Is it a regression from previous versions?

Unknown; no matched stock-version regression range established.

In which sandbox type you have this problem?

In a standard isolation sandbox (yellow sandbox icon).

Can you reproduce this problem on a new empty sandbox?

I can confirm it also on a new empty sandbox.

What is your Windows edition and version?

Windows x64 10.0.22631 / build 22631; edition not recorded.

In which Windows account you have this problem?

Not relevant to my request.

Please mention any installed security software

Not established in this report; security software has not been ruled out.

Did you previously enable some security policy settings outside Sandboxie?

Not established. The account-type dropdown has no Unknown choice; Not relevant is selected only as a placeholder, not evidence that account/UAC settings are irrelevant. The no-crash answer refers only to the reported text-commit failure, not unrelated diagnostic runs.

Trace log

No response

Sandboxie.ini configuration