[BUG] Previews broke in 12.0.3 + Chrome

Describe the bug I recently noticed previewing (as described in the react-dropzone docs) isn’t working anymore. When selecting an image from the user filesystem, Chrome will show a broken image placeholder instead of the actual image. I was only able to reproduce this in Chromium-based browsers (Chrome/Edge), others (Safari/Firefox) seem to be fine.

To Reproduce Steps to reproduce the behavior:

1. Go to https://react-dropzone.js.org/#section-previews
2. Click on the dropzone
3. Select any image file
4. See the broken image placeholder

Expected behavior I expected to see a preview of the to be uploaded image.

Screenshots

Desktop (please complete the following information):

• OS: macOS 12.2.1
• Browser: Chrome
• Version: 98.0.4758.109 (Official Build) (arm64)

Additional context According to git bisect the first commit where this issue starts to appear is: https://github.com/react-dropzone/react-dropzone/commit/dbaec3f5ac48c21ad15f71aaaa0ac330a557a2ce

[RileyMShea]

Both 12.0.4 and 12.0.2 have the same issue for me. My guess is newer chrome versions are either slower at writing the preview to disk or faster at revoking the ObjectURL(or both).

https://stackoverflow.com/a/63111446

Revoking a blob:// URI is a synchronous operation, downloading a file on the other hand is not.

Even though the data can be in memory and thus downloaded really fast, it is not always the case. The Blob’s data may not even be in a single place, for instance some blobParts could be in memory, some others on user’s disk or even in a shared folder access through a network. Also simply requesting the OS for access to write can actually be made asynchronously.

So by the time you call revokeObjectURL, the browser may still haven’t had the time to write your file to disk and when it tries to do so, or to access a new blobPart, there is no more pointers available at the provided address.

There is unfortunately no event letting us know when this writing to disk is done, at least not until the native-file-system API becomes official, so the best we can do for now is to wait a fair amount of time before revoking the blob:// URI. For reference, FileSaver.js does wait 40s.

Current workaround

I doubt it’s the best way but my current solution just adds a sleep >=100ms before the revoke so the blob has time to be written to disk. It at least seems to work on localhost that way.

  useEffect(() => {
    // Make sure to revoke the data uris to avoid memory leaks
    const sleep = (ms: number) => new Promise((resolve) => setTimeout(resolve, ms))
    const cleanup = async () => {
      await sleep(100)
      files.forEach((file) => URL.revokeObjectURL(file.preview))
      console.log("revoked")
    }
    cleanup()
  }, [files])

[Uluwatta]

Just noticed this issue 😃

Following PR might fix this, not sure whether it’s the perfect fix but making sure that the blob/data URLs are revoked after image load and component unmount will help avoid urls to get revoked before its consumption

https://github.com/react-dropzone/react-dropzone/pull/1172