Clicking PR title looses focus

[bpasero]

[alexr00]

This is so that that screen readers can know that something has opened. @meganrogge FYI.

@bpasero, is there a reason that you expect it to keep focus?

[bpasero]

@alexr00 all trees/lists should behave consistently:

• single mouse click: focus remains
• double click: focus moves
• enter/cmd+down: focus moves

[alexr00]

Hmm. Looks like the "Open Description" command is special. To pass through the click modifiers, we must use the vscode.open or vscode.diff commands. We don't pass through click modifiers for other commands, and we don't have a way for commands to opt into this. "Open Description" cannot use vscode.open, because it opens a webview.

Because of this, I actually can't handle https://github.com/microsoft/vscode-pull-request-github/issues/5333 right now either.

It looks like we need a way to let commands opt in to receiving click modifiers, or let opening webviews be done with vscode.open.

[alexr00]

@mjbvz is there a way I can open a webview by using vscode.open?

[mjbvz]

@alexr00 I don't think so. We don't expose a uri for the webview to extension but every WebviewInput does have a unique uri. Maybe if you can get a hold of that vscode.open would work but I've never tested this

[alexr00]

The uri changes every time the webview is opened, so it doesn't seem like this will work. Closing as out of scope.

[hediet]

I don't understand why this is out of scope. Is this because webviews always get focused when they open?

[alexr00]

I marked it out of scope because unless something changes with how webviews are allowed to be opened, I don't intend to fix it. We need the current behavior for accessibility.

[hediet]

We need the current behavior for accessibility.

Can you only do it when the screen-reader mode is turned on?

I'm quite sure this wouldn't break anyones workflow, but provide a more consistent experience.

[alexr00]

Yes, only doing this when screen-reader on seems reasonable.

[alexr00]

@meganrogge is there any way I can tell from an extension whether the user has accessibility mode turned on? I see the setting has an auto option, which means that I can't know for sure just based on the setting.

[meganrogge]

We don't have API for that currently.

[meganrogge]

Could you check the context key from the extension though? accessibilityModeEnabled

[alexr00]

I would need to be able to check the context value dynamically, not in the package.json, as this command is set on the tree item and not through menus in the package.json.

We don't have an API command to get a context value, just the one to set a context value.

[alexr00]

Moving to the backlog as this requires API.