JAWS + Chromium browsers issue: combobox on ESC (clearing field) exits into browser mode

[iseatz-zgoodwin]

Brief description of the issue
This issue happens only JAWS + Chrome/Edge. It doesn't happen with NVDA (tests on Edge/Chrome/Firefox) nor VO (Safari) nor JAWS + Firefox. (Note: for NVDA we added slight time out + blur to help to pull back to form editing mode).
We tried to add various fixes: forcing to focus on the input after a delay, triggering onBlur(), using aria-live "input is ready" to lure JAWS back into form editing mode, used requestAnimationFrame() instead of setTimeout to allow Jaws to catch up with Chrome accessibility tree but so far nothing works.
The concern is that per W3C ESC to clear the field is an established pattern. I tested various libraries "autocompletes" (combobox component), and all have the same issue.
Any tips from JAWS team how to force to keep form editing mode after ESC is appreciated!

JAWS version
2025.2505.43

Name and version of the OS and browser
Chrome v 136.0.7103.114
Edge v 136.0.3240.76
Windows 10 Pro 22H2 v 19045.5854

Expected result
When combobox list is open - on ESC ESC to close and clear the field; or when list is closed and input is filled - on ESC clear the field and allow user to type in the field (stay in form editing mode)

Actual result
When combobox list is open - on ESC ESC - closes and clears the field but cannot type in the field - letters refer to keys in browser mode; or when list is closed and input is filled - on ESC clears the field but cannot type in the field. In order to type, user would need to TAB and SHIFT TAB, then type.

Test case that demonstrates the issue - provide linked test case codepen/JSbin etc.
https://www.w3.org/WAI/ARIA/apg/patterns/combobox/examples/combobox-autocomplete-list/

[TPGJRogers]

I believe this issue is substantially the same as #901. I will check this one when the fix for 901 becomes available and file a bug for this issue if still necessary.