Read script carets without blocking the UI thread - #20523
xperiandri wants to merge 6 commits into
Conversation
✅ Release notes checked
|
This comment has been minimized.
This comment has been minimized.
89eaf2a to
550abf6
Compare
T-Gro
left a comment
There was a problem hiding this comment.
🤖🕵️ Please shorten the description using this guidance. Focus on the problem and why the change is needed, in simplified technical English. Leave the implementation inventory to the Files tab and retain necessary caveats.
550abf6 to
29779b0
Compare
86f3ffa to
4c110d6
Compare
xperiandri
left a comment
There was a problem hiding this comment.
Addressing the inline review feedback in the updated branch.
4c110d6 to
40c0cb9
Compare
|
🔍 Tooling Safety Check — Affects-Build-Infra, Affects-Design-Time, Affects-Restore
|
Head branch was pushed to by a user without write access
530c52d to
75fa3cb
Compare
The project options reactor looked up the caret itself through ServiceProvider.GlobalProvider, the RDT, IVsTextView and an IVsTextViewEvents connection point, all of which need the UI thread. When the UI thread synchronously waited on project options (breakpoint validation when a document frame is shown), the reactor waited for the UI thread and the UI thread for the reactor. An IWpfTextViewCreationListener now publishes the caret of the focused editor into the text buffer's properties, and the reactor only reads it. Only scripts look for it: FCS uses the caret only to skip the `#r "nuget: ..."` line being typed. Fixes dotnet#20522 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Only the shared FocusedCaret.Position field needed to become `option` for the atomic reference write; the reactor's own local binding was converted along with it for no reason. Route it back through ValueOption and land on `option` once, at the two points that need it. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
75fa3cb to
1cef1f4
Compare
Fixes #20522
Visual Studio could hang for good: the project options reactor asked the UI thread for a script's caret (to know whether an
#r "nuget: …"line was still being typed) while the UI thread was itself synchronously waiting on the reactor, resolving a breakpoint in the same file. The UI thread now publishes the caret itself, through the text buffer the reactor already reads; the reactor never waits on the UI thread again, and only scripts look for a caret at all.Moving focus away from a script now submits its pending
#r "nuget: …"line, where before only moving the caret to another line did — the caret is unknown once nothing has focus.