Skip to content
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

allow commands to run from terminal accessible view #194246

Merged
merged 5 commits into from
Oct 2, 2023
Merged

Conversation

meganrogge
Copy link
Contributor

Allows a SR user to go back to the accessible view after invoking Run Recent Command, Go to Recent Directory, or when escaping from Open detected link

fixes #193988

@meganrogge meganrogge self-assigned this Sep 26, 2023
@meganrogge meganrogge added this to the September 2023 milestone Sep 26, 2023
Copy link
Member

@Tyriar Tyriar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a pretty big change to go in after testing, it doesn't seem too critical as it's about canceling an action so would it be better to merge in October?

@meganrogge
Copy link
Contributor Author

meganrogge commented Sep 27, 2023

I wondered about that, but this is a regression bc the following worked before:

  • open accessible buffer
  • run recent command
  • focus remains in accessible buffer

Without this change:

  • open accessible view
  • run recent command
  • focus is lost

With this change:

  • open accessible view
  • run recent command
  • focus is in accessible view

@meganrogge
Copy link
Contributor Author

Actually, the above case can be fixed by setting focusAfterRun to accessible-buffer

Comment on lines 76 to +77
show(provider: IAccessibleContentProvider): void;
showLastProvider(id: AccessibleViewProviderId): void;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of firing an event with an id back to another provider (circular dep), can we indicate in the show call that we want to go back upon exit/close. Then manage it all inside the a11y view service?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, because at the time of the show call, we don't know that we want to go back.

Show is called before run recent command is invoked for example.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But the service knows what came before, so the second provider could signal that it was canceled and it should open the one before. For example, onClose: Event<{ reopenLast: boolean }>?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The issue is we only want to reopen last onClose for certain cases. And the provider isn't aware of what those cases are.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure what you mean by "second provider" 🤔 . The parties of interest here are the original provider and the quick-pick / action that interrupts / hides it temporarily.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh I get it. It just feels a little flimsy right now and easily breakable. Could we do something to make it more reliable? Tests that verify it interacts nicely with the second quick pick would be good

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I think smoke tests would be needed for that?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could be good, but I can just imagine the flakes now... 😅

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Smoke tests would be best yeah. I would think they'd be fairly reliable if all they do is verify the view is up, not validate the contents.

@meganrogge meganrogge merged commit 43a2ba6 into main Oct 2, 2023
6 checks passed
@meganrogge meganrogge deleted the merogge/quick-view branch October 2, 2023 16:26
Alex0007 pushed a commit to Alex0007/vscode that referenced this pull request Oct 26, 2023
allow commands to run from terminal accessible view
@github-actions github-actions bot locked and limited conversation to collaborators Nov 16, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Accessibility] Terminal accessible view is auto-closed when closing select link
2 participants