Broken <img> while loading

[paolo-g]

Am having an issue using meteor-file-collection for displaying images. I have no problem GETting the images using the md5 URI, but when I try use the same path in an src or ng-src, the browser shows a broken image graphic until the data is ready from mongo.

In other words, it works eventually, but the UX is poor in the meantime.

Is there any way, like a data trigger of some sort, to know when the image is ready to be displayed? Am I missing something here?

ps. Thanks for such a great, flexible tool! Has been a pleasure to work with thus far.

[vsivsi]

Hi the sample app handles this via a reactive template mechanism: https://github.com/vsivsi/meteor-file-job-sample-app/blob/master/sample.html#L48-L59

When the file/thumbnail is ready to view, the reactive state change drives the DOM to attempt to load the image.

[paolo-g]

Thanks for the reply @vsivsi,

So it seems that you are setting the thumbCompletion yourself here: https://github.com/vsivsi/meteor-file-job-sample-app/blob/master/sample.coffee#L573

Which I imagine is due to something in your spec where the image is shown after being uploaded.

My situation is different, because I don't have to show the image after uploading it to the DB. The user sees it later in the flow, so it's already in the DB, but while (as you put it) the DOM attempts to load the image, there is a broken image graphic. In some cases, no matter how long I wait, the image never displays. I'd say it works about half the time. Does that make sense?

My code is just: <img ng-src="/gridfs/images/md5/{{ image.md5 }}" />

It works just as often when I GET the URI directly with my browser. When it fails, the error reported by the browser's network inspector is 403 (forbidden)

[vsivsi]

Can you reproduce this behavior on your setup using the simple sample app? https://github.com/vsivsi/meteor-file-sample-app

You should be able to upload images to the DB, and then later reload the page and have the images promptly and correctly load (without the broken image or 403 errors).

403 errors from file-collection always (and only) result from allow/deny rules not being satisfied. https://github.com/vsivsi/meteor-file-collection/blob/master/src/http_access_server.coffee#L311

That is, per the HTTP spec, permission problems. Perhaps you have a race condition affecting your permission checking, either on server and/or the client?

[paolo-g]

@vsivsi it seems it does have to do with the permission checking, but my code is identical to your example: https://github.com/vsivsi/meteor-file-collection#example

read: function (userId, file) { return (userId === file.metadata.owner); },

When I console.log, the userId is sometimes null, so I just return true at the moment and it works. Any ideas why there would be a race condition on userId?

My stack: METEOR@1.2.1 vsivsi:file-collection@1.3.2

[vsivsi]

Yup!

See:

https://github.com/vsivsi/meteor-file-sample-app/blob/master/sample.coffee#L164-L169

https://stackoverflow.com/questions/24445404/how-to-prevent-a-client-race-condition-between-meteor-userid-and-subscription