Repository navigation
Trusted domain dialog in web doesn't return focus to previously clicked element when canceled. #170442
Description
This can be trivially reproduced with the GitHub Pull Requests and Issues extension:
- Open a pull request on insiders.vscode.dev
- In the pull request description, leave a comment with a link to an external domain.
- If you've trusted the workspace, set
"workbench.trustedDomains.promptInTrustedWorkspace": true - Tab to the link that you made in step 2.
- Enter.
- In the resulting trusted domain dialog, tab to cancel and cancel.
- 🐛 Focus is not restored (this works property on desktop with the native dialog).
Activity
alexr00 commentedon Jan 3, 2023
Discovered by the accessibility testing team in microsoft/vscode-pull-request-github#4242
fsteffi commentedon Jan 9, 2023
GitHubTags:#A11ySev3;#A11yTCS;#A11yMAS;#DesktopWeb;#Visual Studio Code Client;#WCAG2.4.3;#BM-VisualStudioCode-Win32-Nov2021;
primary bug:microsoft/vscode-pull-request-github#4242
sbatten commentedon Mar 6, 2023
Alex Ross (@alexr00) I'm not sure what I can do on my side. The custom dialog takes the active element before showing and restores it after the dialog is dismissed. In this case, the active element is the iframe for the webview. I think the webview content provider may need to hand focus coming back to the iframe and decide if it should restore focus to the previously active element.
alexr00 commentedon Mar 7, 2023
SteVen Batten (@sbatten) I assumed that it was fixable by the custom dialog since the issue doesn't happen with the native dialog (and since it is something that will affect all extensions with webviews). Does this need to be fixed by individual extensions?
sbatten commentedon Mar 7, 2023
The native dialog doesn't have this issue because it doesn't truly steal focus, its a separate window. In custom dialogs we try our best to restore focus to mimic the behaviour of a native dialog but since the focused element is inside a webview, we need a webview specific solution. After chatting with Matt Bierner (@mjbvz) we propose that the PR extension handle this when the iframe is refocused. I'm not sure if the PR extension keeps some internal focus state to handle tab navigation. However, if there is a general webview solution, we can pull that up. At the dialog level it is impossible for me to properly restore focus to a specific element inside the iframe unfortunately.
1 remaining item
isidorn commentedon Mar 24, 2023
Thanks for starting this discussion, and a friendly reminder that we have to tackle this in April for compliance reasons.
Scott O'Hara (@scottaohara) what do you think? Somewhat similar to our previous webview focus discussion? If the custom dialog returns the focus to the WebView (outer element) would that be enough to reduce severity to 3? Otherwise VS Code can not pass focus back to the exact element as SteVen Batten (@sbatten) explained above.
sbatten commentedon Mar 27, 2023
We are already passing focus back to the outer webview at the dialog layer.
isidorn commentedon Mar 27, 2023
Thanks. Let's see what Scott O'Hara (@scottaohara) says.
scottaohara commentedon Mar 27, 2023
i imagine that'll be the best you can do, assuming these would be cross-origin iframes.... moving focus to the iframe of the webview and then letting the extension teams reset focus back to the last focusable element once focus is re-detected back in the iframe. based on the linked issue, as long as that is a common representation of this issue, it does seem like it'd be fine as a sev3, so long as focus was moved back to the iframe/iframe's container, and not to the browser chrome.
alexr00 commentedon Mar 28, 2023
I've verified that focus does return to the iframe, but sometimes tabbing from the iframe takes me to the browser chrome. It actually appears to exactly alternate:
Matt Bierner (@mjbvz) do you know why tabbing from the outer iframe might do this?
sbatten commentedon Apr 10, 2023
Matt Bierner (@mjbvz) do you have any idea why that might be the case?
sbatten commentedon Apr 10, 2023
Isidor Nikolic (@isidorn) Scott O'Hara (@scottaohara) how do we get this bumped down to sev3 as discussed?
scottaohara commentedon Apr 10, 2023
fsteffi should be able to help here.
fsteffi commentedon Apr 11, 2023
hi SteVen Batten (@sbatten) severity has been reduced
mjbvz commentedon Apr 20, 2023
SteVen Batten (@sbatten) Alex Ross (@alexr00) Possibly because the webview is structurally and the end of the dom (outside of the normal workbench dom). We need to do this so that the webview can be moved around without being recreated and destroyed. Not sure why it only sometimes happens though
Mana-swi commentedon Aug 14, 2026
#a11ydb-focus-lost-on-action;