-
Notifications
You must be signed in to change notification settings - Fork 709
dialog: Focus first control on open #2377
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
Closed
Closed
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
Oops, something went wrong.
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.
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.
We can't use defer for this, we was tired for this.
If user operations fast to close, this method will have unexpected behaviors
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.
Thank you for the review. I agree that using
deferhere is risky, especially when the dialog is opened and closed quickly.I revisited the focus timing issue. The goal of this PR / issue is still to focus the first focusable control automatically when a dialog opens. The difficulty is that
focus_next(cx)relies on tab stops from the already rendered frame, while focusable children in a newly opened dialog are only registered during the current render/paint phase. So callingfocus_next(cx)synchronously fromopen_dialogorDialog::renderdoes not reliably discover the new dialog children; delaying it withdefermakes discovery work, but introduces the lifecycle issue you pointed out.I see two possible directions:
Keep the original automatic behavior, but implement it without
defer. This likely requires a synchronous initial-focus scope/registry during dialog rendering, where focusable descendants register theirFocusHandlewhile rendering and the first eligible descendant is focused once. This preserves the original behavior, but the change is larger and may need to touch more focusable components.Use a smaller explicit API, for example:
Then Root::render_dialog_layer can perform a one-shot focus handoff only if the dialog container still owns focus. This avoids defer and avoids focus_next, but it changes the behavior from automatic discovery to caller-provided initial focus.
For this issue, would you prefer that we keep the original automatic “first focus handle” behavior even if the implementation is larger, or would the explicit initial_focus API be acceptable as a smaller and safer change?
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.
They are not a good solution.
Actually, we have already considered for this before, but still not get a good choice.
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.
Thank you for your confirmation.
After trying the two solutions mentioned above, I explored a new direction: using a "one-shot"
on_focus_inlistener on the dialog container, hoping to transfer focus during the lifecycle of the focus in GPUI—specifically after the newly rendered frame has been officially replaced and displayed.However, under the current GPUI public API, this approach still does not work.
Context::on_focus_inis activated via thedefermechanism; this means that new subscribers are inactive before the activation actually occurs. Since theopen_dialogmethod completes both the listener registration and the focus operation on the dialog container within the same update cycle, the subscription is not active when the first "focus-in" event is triggered, causing the listener to miss the initial focus lifecycle.In summary, based on the current API, I have not been able to find an ideal component-level solution that satisfies all of the following constraints:
initial_focusAPI.Given this, I will temporarily close this PR (Pull Request) until GPUI provides more robust low-level focus handling primitives.