UI: Fix unresponsive page after closing Clear / Mark-as dialog#67645
Closed
pierrejeambrun wants to merge 2 commits into
Closed
UI: Fix unresponsive page after closing Clear / Mark-as dialog#67645pierrejeambrun wants to merge 2 commits into
pierrejeambrun wants to merge 2 commits into
Conversation
…t acting
Opening a Clear or Mark-as-success/failed dialog on a Dag Run or task
instance and closing it without confirming left the page unable to
receive any click (scroll still worked). The cause was the parent
button rendering its dialog with ``{open ? <Dialog .../> : undefined}``,
which yanks the component out of the tree the moment ``open`` flips
to ``false``. Chakra never gets to run ``Dialog.Root``'s close
transition, so the body-scroll lock / ``pointer-events`` overlay it
applies on open stays on the document.
Drop the conditional wrapper in every Clear / Mark-as button (plus the
``ClearTaskInstanceDialog`` mount on the Task Instance Header) so the
dialog stays mounted across open/close cycles. ``lazyMount`` (already
set on every dialog) defers the first mount until the user actually
opens it, and the ``open`` prop drives the visibility transition
cleanly thereafter.
``ClearRunDialog``'s ``useClearDagRunDryRun`` was the only dry-run
query in this set that didn't already gate on ``open``; adding
``enabled: open`` so the now-always-mounted dialog doesn't fire it
in the background.
Now that the dialog stays mounted across open/close cycles to let Chakra's close transition run cleanup, the local form state (``note``, segmented options, ``preventRunningTask``) survives between opens too. That re-introduces the leak apache#47071 originally fixed by remount-on-each-open: type a note, cancel, reopen, and you'd see your own typed text instead of the run/TI's actual note. Reset that state in a small effect when ``open`` flips to false, so each new open starts from the same defaults the freshly-mounted component would have shown — without giving up the close transition.
This was referenced May 28, 2026
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Symptom
Open a Clear or Mark-as-success/failed dialog on a Dag Run or task
instance, close it without confirming, and the page becomes
unresponsive — only scroll works. Reopening another dialog doesn't
help; only a hard refresh recovers.
Root cause
The buttons that own these dialogs render them like
When the user closes the dialog,
openflips tofalseand theparent unmounts the dialog component synchronously. Chakra never
gets to run
Dialog.Root's close transition, which is what removesthe body-scroll lock +
pointer-eventsoverlay it applies on open.The overlay stays on
document, blocking every click while stillletting wheel events through.
Fix
Drop the conditional wrapper in the five callers (
ClearRunButton,MarkRunAsButton,ClearTaskInstanceButton— three discriminatorbranches,
MarkTaskInstanceAsButton, and theClearTaskInstancemount on the Task Instance Header) and always render the dialog.
lazyMount(already set on everyDialog.Root) defers the veryfirst mount until the user actually opens the dialog, and the
openprop drives visibility cleanly across subsequent cycles.ClearRunDialog'suseClearDagRunDryRunwas the only dry-runquery in this set that didn't already gate on
open; addingenabled: openso the now-always-mounted dialog doesn't fire itin the background. The four other dialogs already do this.
Screenshots
UI bug-fix with no visual change — the dialog looks the same, it just
stops trapping the page after close. No screenshot can show that;
exercising in the browser is the only way to confirm.
Was generative AI tooling used to co-author this PR?
Generated-by: Claude Code (Opus 4.7) following the guidelines