Roslyn: Decompilation navigation box is not cancellable

Created on 4 Jul 2018  ยท  3Comments  ยท  Source: dotnet/roslyn

Version Used:
Visual Studio Int Preview 27823.0.d15.8

Steps to Reproduce:

  1. Create a project with a reference to a type in a different assembly (i.e.: System.Console)
  2. Set the caret in the aforementioned type
  3. Enable decompilation in Tools > Options dialog
  4. Press F12

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.
image

4 - In Review Area-IDE Bug

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.

All 3 comments

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ashmind picture ashmind  ยท  3Comments

joshua-mng picture joshua-mng  ยท  3Comments

AdamSpeight2008 picture AdamSpeight2008  ยท  3Comments

codingonHP picture codingonHP  ยท  3Comments

binki picture binki  ยท  3Comments