Azurestorageexplorer: Copy URL command unexpectedly encodes "/" as "%2F"

[craxal]

Storage Explorer Version: 1.13.0
Build Number: 20200430.5
Platform/OS: All
Architecture: All
Regression From: 1.12.0

Bug Description

In previous versions of Storage Explorer, Copy URL returned a URL like this:
https://myaccount.blob.core.windows.net/mycontainer/folder/file.html

However, in 1.13.0, COPY URL returns a URL with encoded slashes like this:
https://myaccount.blob.core.window.net/mycontainer/folder%2Ffile.html

For many file types, this isn't an issue. But if I paste the encoded URL into a browser window, some files don't open properly, such as HTML files generated by Adobe Animate CC.

Steps to Reproduce

1. Launch Storage Explorer and open a blob container.
2. Set the container's Public Read Access to "blob".
3. Create a virtual folder in the blob container.
4. Upload an HTML file generated by Adobe Animate CC to the virtual folder.
5. Right-click the uploaded blob and select Copy URL.
6. Paste the copied URL into a browser window.

Expected Experience

The file opens and performs as expected.

Actual Experience

The file opens with errors or missing components.

Additional Context

This bug was originally reported by @egdedudette.

[cicorias]

I just saw this today after updating Storage Explorer.

I can confirm that if I navigate via the Azure Portal (portal.azure.com) to the same container/file and use the "Copy" to clipboard icon - that there are NO URL encoding of slashes to %2F. Yet in Storage Explorer %2F ---

The storage account is being accessed using normal RBAC via Storage Explorer and not a SAS.
The type is StorageV2 (general purpose v2)

https://ACCOUNT.blob.core.windows.net/slbdrops/slb-curl%2Fcurl-build_22_20200506_101%2Fcurl-build.zip

[craxal]

The URL comes from the Azure Node client library, and we updated to v12 between Storage Explorer 1.12.0 and 1.13.0. We'll need to get in touch with them and find out why the URL behavior is different in v12 than in previous versions.

[jasongaylord]

The URL comes from the Azure Node client library, and we updated to v12 between Storage Explorer 1.12.0 and 1.13.0. We'll need to get in touch with them and find out why the URL behavior is different in v12 than in previous versions.

Glad it has been identified. It's a big pain.

[egdedudette]

Any news on this?

[craxal]

According to @XiaoningLiu, this was an intentional change on the part of the client SDK. See Azure/azure-sdk-for-js#6886 for reference.

@egdedudette We understand the inconvenience this problem has caused, and we're working on a solution. We will need some time to run tests to make sure we don't break anything, because a lot of different parts rely on the code where the URL comes from.

@jasongaylord As a workaround, are you able to replace the %2F encodings with slashes manually and get a working URL?

[jasongaylord]

@craxal For now, that's what I've been doing. When I drop a bunch of blobs, it's somewhat time consuming, but it works for now.

[craxal]

@jasongaylord Thanks. Just wanted to make sure you had a workaround while we're working on a solution.

[jasongaylord]

@JasonYeMSFT I didn't notice anything in the build version. Is it closed because its in an Insider build?

[JasonYeMSFT]

We are making an 1.13.1 release which contains a fix for this issue. It is being propagated to the data centers and should be available soon.

[jinglouMSFT]

@jasongaylord you can download 1.13.1 from the "Releases" tab in this repo. We just released the bits there. If you prefer being prompted to upgrade, you will need to wait for at least another day for the bits on Microsoft download center to be propagated to all data centers before you see the prompt.

[jasongaylord]

Thanks @JasonYeMSFT and @jinglouMSFT! I blogged about it. Should be posted by early morning. Appreciate the quick turnaround.

[jasongaylord]

FWIW, version 1.13.1 has not yet propagated. I'm going to get it from the releases tab.