Mitigate the negative effects of double x button in secondary, sidebar. #425
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Because, secondary sidebar in vscode has a "close" button in top right corner, the user is faced with two "X" buttons that do different things; one closes the secondary sidebar and in effect hides our extension and the second closes our extension completely.
Solution
To mitigate the negative effects this PR overrides the command used to hide secondary sidebar and closes React native IDE completely before hiding it, that makes two buttons perform similar actions instead of doing two different things, which is an improvement.
Hiding the second button
The natural question to ask is why can't we disable, our "close RNIDE" button when IDE is in secondary sidebar. Unfortunately there is now reliable way to check in which sideBar the viewContainer contributed by an extension is located at any given time. There is a closed issue on that topic here. One workaround for that would be to check if context key "activeAuxiliary" has value matching our extension contributed viewContainer, because since it is an activeAuxiliary it has to be in Auxiliary SideBar, unfortunately the id of Extension contributed view Containers is randomly generated, you can read the code here the first relevant line is 502.
There is hope of discovering the generated viewContainer id by checking the activeAxiliary and activeViewlet context fields while we know about its location, but it would require a getContext() API that is not currently implemented, an active issue on that can be found here.