You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, setupTokenCounting() can call onEdit() with a null textarea, which throws when onEdit() unconditionally calls addEventListener. This can break token counter initialization at runtime if the textarea selector doesn’t match the DOM structure.
Severity: action required | Category: correctness
How to fix: Guard null textarea in setup
Agent prompt to fix - you can give this to your LLM of choice:
Issue description
setupTokenCounting() can pass a null textarea into onEdit(), which throws because onEdit() unconditionally calls elem.addEventListener.
Issue Context
This breaks token counter initialization when the selector #${id} > label > textarea doesn't match (DOM/layout differences, Gradio markup changes, etc.).
Fix Focus Areas
javascript/token-counters.js[46-66]
javascript/ui.js[423-437]
Suggested fix
In setupTokenCounting, extend the existing guard to also check textarea (and/or guard inside onEdit):
Hi, Switching the UI-loaded trigger from #txt2img_prompt to get_uiCurrentTabContent() can fire onUiLoaded callbacks before their required elements exist, causing those callbacks to throw and silently fail (exceptions are caught). This can break UI behaviors like mobile layout rearrangement on initial load for some render timings/configurations.
Agent prompt to fix - you can give this to your LLM of choice:
Issue description
onUiLoaded callbacks can run too early because the load condition was broadened from a specific element (#txt2img_prompt) to any visible tab container. Callbacks that assume specific elements exist can throw and never apply their behavior.
Issue Context
Exceptions inside callbacks are caught and logged, so the app may continue, but features can be broken on initial load depending on render timing.
Fix Focus Areas
script.js[118-136]
Suggested fix options
Choose one:
Make the readiness predicate stronger (wait for a stable/known element set), e.g. require both a tab content and .tab-nav buttons, and/or a known per-tab anchor element.
Delay execution by a tick (e.g. requestAnimationFrame/setTimeout) and re-check readiness before firing.
Keep the new predicate, but audit/patch high-risk onUiLoaded callbacks to null-check required DOM nodes (e.g. mobile.js insertBefore targets).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #16322
Summary
This PR restores the visibility of the hidden tabs button in the UI.
Changes
Testing