[Bug] Browser/web UI: input box disabled & no abort button during long streaming responses

[Innerpeace1990]

Summary

In the browser/web frontend (the in-browser chat UI, not the TUI), while the agent is streaming a response, the message input box becomes disabled/unclickable and there is no visible "stop/abort" control. During a long-running task this makes the UI effectively frozen from the user's perspective — you cannot type new instructions or interrupt the run, and can only recover by refreshing the page (which loses the in-progress session state).

Context / why this matters

I ran a long, multi-step automation session (~160+ turns) inside the browser frontend. The model entered a repetitive reasoning loop, continuously streaming large amounts of thinking/output. Because the input box was locked for the whole streaming period, I had no way to steer or stop it, and the page bottom kept scrolling with streamed content until I had to refresh.

Note: This is reported against the browser/web UI, so it is distinct from the TUI-specific issues #627 (TUI v3 keyboard input) and #472 (TUI v2 markdown rendering timing). Mentioning them only to show I checked for duplicates.

Observed behavior

• While the assistant is streaming a response, the text input cannot receive focus / typing has no effect.
• There is no obvious Stop / Abort button to terminate the current streaming run.
• For very long streams the UI keeps appending content and feels unresponsive; the only recovery is a page refresh.

Expected behavior

• The input box should remain focusable during streaming (typing could be buffered until the run ends), OR
• A clearly visible Stop/Abort button should be available so the user can interrupt a long/looping run safely without refreshing the page or killing the backend task (consistent with the "non-destructive recovery" request in TUI v3 becomes unresponsive to keyboard input while BBS task is running #627).
• Ideally, a safeguard for runaway/looping responses (e.g. auto-suggest abort after N repeated identical reasoning steps) so the UI doesn't get locked for an extended period.

Environment

• Frontend: browser/web chat UI (Chrome)
• OS: Windows
• Scenario: long autonomous task (~160+ turns), model = GLM-5.2, streaming output enabled

Additional notes

• The backend task/process stayed alive (similar to TUI v3 becomes unresponsive to keyboard input while BBS task is running #627's note that "killing the process is unsafe") — only the frontend input was blocked.
• I've already mitigated on my side (redirecting background-process stdout), but the frontend abort + input-during-streaming behavior still needs a product-level fix.