The blob container doesn't auto disappear if delete it from view all containers explorer

[v-xianya]

Storage Explorer Version: 1.35.0-dev (98) Build Number: 20240604.2 Branch: main Platform/OS: Windows11/Windows 10/Linux Ubuntu 22.04/MacOS Sonoma 14.5(Apple M1 Pro) Architecture: arm64/x64/x64/arm64 How Found: From running test cases Regression From: Previous release (1.34.0)

Steps to Reproduce

1. Open 'Settings -> Services' -> Select 'View all' for the setting 'Storage Nodes Trailing Action'.
2. Refresh the tree view -> Expand one storage account -> Create a blob container.
3. Click 'View all' -> Delete the blob container on the view all containers explorer.
4. Check whether the blob container auto disappear.

Expected Experience

The blob container auto disappears.

Actual Experience

The blob container doesn't auto disappear.

[craxal]

@v-xianya Do you mean the blob container node in the tree view doesn't disappear?

[v-xianya]

@craxal The blob container on the view all containers explorer doesn't auto disappear.

[craxal]

@v-xianya I am observing that the container is removed from both the tree view and the explorer as expected, either when deleting from the tree or from the explorer. Is this still reproducing for you? If so, can you please provide a GIF/video?

[v-kellyluo]

@craxal , Verified this issue on the build 20240717.2. Reproduce. Here is the GIF:

[craxal]

I've finally been able to reproduce on my Windows machine (still not my Mac). It's very bizarre; the event that's raised in order to close the tab doesn't seem to be returning, so the code that sends the refresh event is never executed. We did notice an error getting thrown about a webview, so I wonder if that's causing issues. Perhaps it's some kind of race condition.

[craxal]

I just figured out that this only reproduces if you don't close the tab for the newly created container before deleting the container. Which means a bug in the tab closing mechanism is interfering with the refresh. Specifically, I think this is related:

The WebView must be attached to the DOM and the dom-ready event emitted before this method can be called.

I think what's happening is we're trying to raise events on the webview after it's been removed. Specifically, the host system is handling frequent requests for clipboard data, but when a tab is closed, the last request no longer has a tab to respond to.

This goes fairly deep, so I think for the time being we can fix this by changing the order of things. We should refresh the tree and container explorer before attempting to close any tabs associated with the deleted container.

[craxal]

Fix merged.

I should note that this bug was only exposed when multi-delete was implemented; it did not create this regression.

[v-xianya]

Verified this issue on the main build 20240724.1. Not reproduce.