Warning Users About The Windows Explorer Zip Archive Preview In JavaScript

In recent years, on a Windows computer, if you double-click on a .zip file - the same way you would navigate into any Folder in the file system - Windows doesn't automatically extract the .zip file contents. Instead, it opens an "Explorer Preview" of the archive, allowing you to view the contents of the archive without actually extracting the embedded files. While this provides some conveniences for the user, it can also break the user experience (UX) in non-intuitive ways. As such, it can sometimes be helpful to alert the user about this non-obvious Explorer experience using JavaScript.

At InVision, I produce a lot of .zip archive files. Which is why I spend so much time writing about the DEFALTE and STORE compression methods, incrementally generating and streaming Zip files on-the-fly, and executing the zip command from a given working directory (using either a proxy shell command or the new directory attribute in Lucee's CFZip tag).

Many of the Zip archive files that I generate are actually "rich reports" that contain an interactive .html file. This HTML file almost always references other files embedded within the archive; which works gang busters, unless you're using the aforementioned Windows Explorer "preview archive" experience. You can tell that you're using this experience if Windows Explorer includes the .zip file extension in the "folder path" and shows you Extraction tools within the toolbar:

As you can see, the .zip file extension is in the Windows Explorer folder path. We haven't unarchived / extracted the file - we've entered into the "archive preview". The problem here is that if you then double-click on the index.html file, Windows extracts that file on-the-fly into a temporary folder:

As you can see, while the index.html file opened in the Microsoft Edge browser as one would hope, it's opening from an AppData/Local/Temp/ location - not from the "Downloads" folder in which the Zip archive is actually stored. In many cases, this isn't a problem. However, if the index.html file references other files within the .zip archive, the relative file paths that you have to use in such a case will not work from this AppData/Local/Temp/ location.

So, any linked images, style sheets, and JavaScript files will break (fail to load in the index.html file).

What you end up with is a broken user experience despite the fact that the user double-clicked into the .zip file in the same way that they would have double-clicked into any other type of Folder. Windows has entered an "Uncanny Valley" - it has something that mostly looks and acts like a "Folder", but which leaves much to be desired.

In order to help the user understand why their experience is breaking, we can use JavaScript to put a spotlight on the contextual problem. Thankfully, when Windows Explorer enters this "preview" mode, the .zip file-extension is present in the window.location.href value. Which means, we can look for this value on page-load and then alert() the user that they've entered into a not-quite-a-folder experience:

Here, we're using the Regular Expression pattern:

\.zip[\\/]

... to see if the .zip string is located right before a path-separator (either back-slash or forward-slash). And, if that pattern is found, we open up a native alert() outlining the potential issue.

Now, if the user double-clicks into the .zip file, enters the Windows Explorer archive preview mode, and then double-clicks into the index.html file, they will see the following:

This is not a great user experience (UX); but, it's a whole heck of a lot better than just letting the file open and allowing the embedded resources to break without any explanation. At least with the JavaScript alert, we can hopefully guide the user to a working solution.

Epilogue on Using Data URLs to Embed Resources Within a Single File

One possible work-around for this Windows Explorer archive preview mode problem is to not have any external resources. And, one way to accomplish that is to embed any external resources as Data URLs directly within the index.html file. So, instead of linking to a relative ./files/report.png image file, you can embed the binary image data as a Base64-encoded value right within the <img> tag itself:

<img src="data:image/png;base64,R0lGODlhEAA{ ... really long value ... }" />

To be clear, this works. But, it should only be used when you have a relatively small amount of data to embed. In my experience, including a lot of data as Base64-encoded values quickly leads to massive file sizes and slow load times (depending on where you're loading the file from). It also means that the user cannot easily "explore" the linked files - something that may be a critical part of the user experience. As such, your mileage may vary.

Enjoyed This? You Might Also Enjoy Reading:

• Generating Rich Server-Side Reports In Lucee CFML 5.3.6.61

You — Get Out Of My Dreams, Get Into My Blog

Live in the Now

Name:

Email:

( I keep this private )

Website:

Comment Etiquette: Please do not post spam. Please keep the comments on-topic. Please do not post unrelated questions or large chunks of code. And, above all, please be nice to each other - we're trying to have a good conversation here.