fix(email): Recipient selector losing focus on mount#642
Merged
Conversation
sedson
requested changes
Dec 15, 2025
…ntrol whether focus should be returned
…en closing the launcher
sedson
approved these changes
Dec 15, 2025
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
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.
Summary
When going from the unified list view to composing an email, the recipient selector would briefly receive focus and then immediately lose it. This was caused by a
Suspenseissue which was triggered by theuseEmailLinkshook that was reading query data inside of a memo to provide a value forstatus(now renamed toisConnected) AND by the logic increateControlledOpenSignalthat tries to focus the previously in focus element when setting the value to false. The problem with the latter is that it will try to focus an element that is no longer there when we transition to a different view like the email compose view and thus trigger cause the element on the new view which should have focus, to lose it.Reading a resource inside of a memo will immediately cause the nearest
Suspenseabove the memo to be triggered because memos are not lazy in Solid 1.0.This also fixes issues with other inputs in blocks not receiving focus when going through the create menu
Screenshots, GIFs, and Videos