-
Notifications
You must be signed in to change notification settings - Fork 2.5k
Fix: "Response" Button Unresponsiveness in Run Agent Tab #672
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Fix: "Response" Button Unresponsiveness in Run Agent Tab #672
Conversation
|
PR | Title | Merged | Author |
---|---|---|---|
#599 | upgrade to bu==0.1.47 | May 15, 2025 | @vvincent1234 |
#583 | Fix/docker | May 10, 2025 | @vvincent1234 |
#583 | Fix/docker | May 10, 2025 | @vvincent1234 |
📊 Summary
The Run Agent tab's user interaction logic, especially around the "Response" button and event handling, has undergone several key changes since its introduction. This area manages how user inputs and agent responses are coordinated in the Gradio-based UI, focusing on responsiveness and event handling.
Magnus Müller's initial implementation (Mar 2024) introduced the agent run workflow with polling via await asyncio.sleep() to wait for user responses or agent task completion. This approach relied on periodic sleeps within an async loop, which was simple but risked blocking the Gradio event loop under certain conditions.
In PR #599 (May 2025), vvincent1234 upgraded browser-use to version 0.1.47 and refactored browser automation logic, but did not address the underlying event handling or polling strategy for the Run Agent tab. The polling-based waiting remained, even as other dependencies and browser automation methods were modernized.
Throughout early 2025, several commits by vincent and vvincent1234 focused on Docker, dependency, and agent feature improvements (e.g., PR #583, May 2025), but left the core user interaction loop unchanged. The polling approach persisted, despite occasional user reports of UI sluggishness.
The unresponsiveness issue became more visible as users reported the "Response" button freezing when multiple actions were attempted in quick succession. This was traced to the use of await asyncio.sleep(), which blocked Gradio's single-threaded event loop, preventing it from handling concurrent UI events.
This history is relevant now because ngocanhnt269's current PR (#672, Aug 2025) directly replaces the polling approach with event-based waiting and enables trigger_mode="multiple", finally resolving the longstanding UI freezing issue rooted in the original design decisions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cubic analysis
1 issue found across 1 file • Review in cubic
React with 👍 or 👎 to teach cubic. You can also tag @cubic-dev-ai
to give feedback, ask questions, or re-run the review.
and not agent_task.done() | ||
): | ||
await asyncio.sleep(0.2) | ||
await webui_manager.bu_response_event.wait() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Waiting solely on bu_response_event can hang if the agent task finishes before the user responds; the event may never be set, causing the coroutine to block indefinitely and freeze the UI. The previous implementation avoided this by also checking agent_task.done().
Prompt for AI agents
Address the following comment on src/webui/components/browser_use_agent_tab.py at line 635:
<comment>Waiting solely on bu_response_event can hang if the agent task finishes before the user responds; the event may never be set, causing the coroutine to block indefinitely and freeze the UI. The previous implementation avoided this by also checking agent_task.done().</comment>
<file context>
@@ -632,11 +632,8 @@ def done_callback_wrapper(history: AgentHistoryList):
last_chat_len = len(webui_manager.bu_chat_history)
yield update_dict
# Wait until response is submitted or task finishes
- while (
- webui_manager.bu_response_event is not None
- and not agent_task.done()
- ):
- await asyncio.sleep(0.2)
+ await webui_manager.bu_response_event.wait()
</file context>
Summary
This PR resolves an issue where the "Response" button becomes unresponsive in the Run Agent tab of the UI. The issue was caused by using await asyncio.sleep() in a loop, which blocked Gradio from handling other click events when those buttons were tied to the same function.
Root Cause
Gradio runs on a single-threaded event loop, and using await asyncio.sleep() (even in small intervals) prevents it from processing other user interactions.
Related Gradio issue: gradio-app/gradio#6749
Solution
This change allows the coroutine to yield properly, giving control back to Gradio’s event loop and keeping the UI responsive.
This ensures the Run button can be clicked multiple times without blocking subsequent actions.
Impact
Prevents UI freezing where the "Response" button would not respond to clicks.
Summary by cubic
Fixed an issue where the "Response" button in the Run Agent tab became unresponsive due to blocking event handling.