Bug: Blocking busy-wait loop in typing handler can freeze the browser

[Agarwalchetan]

The typing handler in EmbeddedChatApi uses a synchronous busy-wait loop to enforce sequential processing of typing events. Because JavaScript is single-threaded, this loop blocks the event loop and can cause the host application to freeze under certain conditions.

---

Affected File

packages/api/src/EmbeddedChatApi.ts

Method: handleTypingEvent

---

Problem

The current implementation relies on a lock enforced via a synchronous loop:

while (typingHandlerLock) {}

Since the event loop is blocked:

• The setTimeout callback intended to release the lock cannot execute
• Multiple rapid typing events can lead to a deadlock
• The UI may become unresponsive or freeze entirely

This is especially likely when multiple typing events arrive in quick succession (common in real-time chat environments).

---

Why This Matters

• Blocks the JavaScript main thread
• Causes degraded UX or complete UI freezes
• Breaks the expected non-blocking behavior of event handling
• High impact in embedded/hosted environments where responsiveness is critical

---

Expected Behavior

• Typing events should be processed sequentially
• The event loop must remain non-blocking
• A failure in one typing callback should not break future typing updates

---

Suggested Solution

Replace the synchronous lock with an asynchronous FIFO queue (e.g., Promise chaining):

• Guarantees ordering of typing events
• Avoids blocking the event loop
• Preserves existing behavior
• Safer and idiomatic for JavaScript

---

Notes

This issue is independent of UI concerns and can be addressed entirely within the API layer.
A fix should not change public API behavior, only internal execution semantics.

---