Version Used:
Visual Studio Int Preview 27823.0.d15.8
Steps to Reproduce:
Expected Behavior:
Warning dialog appears that decompilation is about to happen. At this point, the user can choose to proceed with decompilation, fallback to metadata-as-source, or cancel the action.
Actual Behavior:
A Yes/No dialog is displayed without a cancel button and the close button is greyed out. This means that unlike most other dialog boxes, you cannot dismiss this one with 'Esc' and the operation cannot be canceled if the user changed their mind. The user is forced to either proceed with the decompilation or viewing the metadata as source.

Tentatively marking as Won't Fix; will update with the results following a design review with the team.
During today's design review, we decided that the desired behavior for this dialog is for Esc, No, and the โ to all behave the same way (navigation proceeds, but uses Metadata as Source instead of decompilation). This is a deviation from certain other cases where cancellation is offered, but is not expected pose a particular challenge for implementation.
I'd like to voice my support for this issue. It's incredibly frustrating to accidentally trigger a scenario that you cannot escape from, and it's particularly bad here because you then not only have to wait for the result but also have to deal with the unwanted tab popping up.
Making the case: I use ctrl-click all the time to navigate around source code, and it is incredibly hard to always know in advance whether something is part of the solution or not. We often model implementations to be similar in style to similar classes (like a custom dictionary offering a set of Try methods), but unless you are observant of the actual dictionary in use, predicting whether a click on TryGetValue will show sources or the dreaded dialog, requires time and mental effort better spent on other things. Being able to quickly and harmlessly escape the decompilation/metadata trap would be a relief.
That said, I'm baffled that it is even necessary to make a case for this. It's not like it's a complicated thing to make a dialog do nothing but go away.
Most helpful comment
I'd like to voice my support for this issue. It's incredibly frustrating to accidentally trigger a scenario that you cannot escape from, and it's particularly bad here because you then not only have to wait for the result but also have to deal with the unwanted tab popping up.
Making the case: I use ctrl-click all the time to navigate around source code, and it is incredibly hard to always know in advance whether something is part of the solution or not. We often model implementations to be similar in style to similar classes (like a custom dictionary offering a set of Try methods), but unless you are observant of the actual dictionary in use, predicting whether a click on TryGetValue will show sources or the dreaded dialog, requires time and mental effort better spent on other things. Being able to quickly and harmlessly escape the decompilation/metadata trap would be a relief.
That said, I'm baffled that it is even necessary to make a case for this. It's not like it's a complicated thing to make a dialog do nothing but go away.