fine-uploader icon indicating copy to clipboard operation
fine-uploader copied to clipboard

IE11/Edge crash on large photo sets

Open lscholten opened this issue 9 years ago • 3 comments

Type of issue

bug

Uploader type

S3, but also with demo uploader on the demo page.

Bug details

Fine Uploader version

5.11.0

Browsers where the bug is reproducible

IE11, sometimes Microsoft Edge

Operating systems where the bug is reproducible

Windows 10

Exact steps required to reproduce the issue

  1. Select a relatively large set (153 photos, ~5.5MB each, total of 860MB)
  2. IE11 will always crash at the n-th photo (can be the 10th, can be the 50th), depending on the computer used.

All of your Fine Uploader initialization JavaScript code

new qq.s3.FineUploaderBasic({
    autoUpload: true,
    button: filePickerElement,
    callbacks: {
        onError: _onError,
        onValidate: _onValidate,
        onValidateBatch: _onValidateBatch,
        onAllComplete: _onAllComplete,
        onComplete: _onComplete,
        onCredentialsExpired: this._onCredentialsExpired
    },
    credentials: credentials,
    objectProperties: _getObjectProperties(filenameFormatter),
    request: this.request,
    retry: {
        autoAttemptDelay: 5,
        enableAuto: true,
        maxAutoAttempts: 100
    },
    scaling: {
        defaultType: 'image/jpeg',
        sendOriginal: false,
        includeExif: false,
        defaultQuality: 75,
        orient: false,
        sizes: [{name: 'small', maxSize: 885}]
    },
    validation: this.validation
});

Detailed explanation of the problem

We use FineUploader to generate smaller versions of photos uploaded by our users, which we then ship to S3. To do the scaling, we use the FineUploader scaling capability. This works perfectly fine on modern browsers such as Google Chrome, but some of our users only use older/worse browsers such as IE11 and Edge.

Our users upload pictures from digital cameras and phones to our application, which we then process. This means that the file sizes can become relatively large. For some users, with large photo sets such as the one described above, the browser will crash. We can reproduce this issue without problems by trying to upload the same photo set in IE11. As we wanted to make sure that the bottleneck wasn't in our application, we've tried to upload the same photo set to some examples on the demo page. The browser also crashes for these example implementations.

We fear that there might be some sort of memory leak, or other memory related bottlenecks in the FineUploader code. Uploading the pictures one by one (manually, and with a queueing system) seems to work just fine. Our gut says it might be related to #1543, but we're not sure.

lscholten avatar Aug 26 '16 07:08 lscholten

As an additional comment; we have used the tool on http://www.easyexifdelete.com/ to strip all EXIF from our photo set. This reduces the total file size from 865 to 861.3 MB, but suddenly the uploads works without problems, both on our implementation and the demos in the demo page.

lscholten avatar Aug 26 '16 08:08 lscholten

If uploading them one by one, but still all in the same session, does not result in a crash in IE11, and if the issue is limited to one browser, this hardly sounds like a memory leak. It might be a while before I am able to look into this, so anything you discover will make this easier to address.

It is interesting that removal of the EXIF data seems to fix the problem for you, but I'd want to be sure that this is indeed a fix and you're not just "getting lucky". I can't imagine, off the top of my head, how EXIF data would be an issue here, especially since you are excluding the EXIF data from the scaled uploaded files.

A terminology note here - scaling refers to generating a smaller image from a reference image and then uploading that image. Scaling for a file only happens just before that file is about to being uploading. The demo page does not do scaling, only preview/thumbnail generation. Thumbnail generation can happen for all submitted image files at once, but there is some staggering in place by default that waits 750ms between preview generation attempts.

I'd be interested to see if you have the same problem when plugging a third-party image scaling library into Fine Uploader (which overrides much of the internal image manipulation logic). See the scaling.customResizer option and the thumbnails.customerResizer option for more details on integrating a 3rd-party image library, like Pica.

rnicholus avatar Aug 26 '16 12:08 rnicholus

Thanks for your reply.

We are also quite confused by the fact that removing EXIF fixes the problem. We've tried another real user data set which failed, and removing EXIF there also seems to fix the problem.

Additionally, we have tried using Pica as a replacement, just like in the example code in the documentation. But the browser still crashes.

lscholten avatar Aug 29 '16 08:08 lscholten