In the FirefoxOS Gallery app, on low-memory Flame devices, it is possible to get the app into a situation where thumbnails are not decoding property or flicker in and out. That is bug 1161734. While investigating that bug, I discovered that if I take a screenshot of the Gallery app to illustrate the problem, the Gallery app can fail to create a thumbnail for the new screenshot image. The failure is at the canvas drawImage() call at line 118 of gaia/apps/gallery/js/MetadataParser.js This is a serious data loss bug for the Gallery app, because when this drawImage call fails, we assume that it is a persistent failure caused by a corrupt image, so the screenshot will be ignored in all future runs of the Gallery app and the user will never see it. The image that is passed to drawImage() is an offscreen image, and it has received a 'load' event before drawImage() is called. The image is a PNG screenshot, so decoding it doesn't even require all that much memory. This may simply be a dupe of 847357, but hopefully it will be a practical motivation to fix the underlying spec compliance issue!

If I add a try/catch around the drawImage call and log the exception, I get this: E/Gallery (10361): Content JS ERROR: Exception in drawImage() [Exception... "Component is not available" nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)" location: "JS frame :: app://gallery.gaiamobile.org/js/metadata_scripts.js :: createThumbnailFromElement :: line 1234" data: no] E/Gallery (10361): at createThumbnailFromElement (app://gallery.gaiamobile.org/js/metadata_scripts.js:1239:9) E/Gallery (10361): at createThumbnailAndPreview/offscreenImage.onload (app://gallery.gaiamobile.org/js/metadata_scripts.js:1570:1) Without that added try/catch, the symptom of this bug is a message like the following in logcat: W/Gallery ( 6589): Content JS WARN: MediaDB: error parsing metadata for /sdcard/screenshots/2015-05-08-13-30-13.png : W/Gallery ( 6589): at metadataError (app://gallery.gaiamobile.org/shared/js/mediadb.js:1880:1) Note that this does not happen every time. If you just launch the Gallery app and take a screenshot, everything may work fine. To reproduce, you need a Flame configured to 319mb of memory, and you need enough photos (100?) to start seeing symptoms of bug 1161734 when you scroll. Once you start seeing those symtptoms, then screenshots often fail in this way.

Setting needinfo for Seth and No-Jun to get this on their radar. Seth: this seems related to bug 1161734 No-Jun: this is not marked as a Gallery bug but it has potentially severe effects for the Gallery app, so I wanted you to be aware of it.

djf can you find out where the exception is being thrown from?

This bug does not affects today's 2.2 nightly. But if I edit prefs.js to add: pref("image.mem.allow_locking_in_content_processes", true); Then this bug does occur on 2.2 If bug 1148696 is uplifted as requested, then this will probably have to be come a 2.2+ bug.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #3) > djf can you find out where the exception is being thrown from? Jeff, I assume you mean where in gecko is it is being thrown from. It has been many years since I used gdb regularly, and I've basically got no clue how to find that out.

Pretty sure this is just bug 1162282, which I just fixed.

BTW, note that bug 1162282 just makes drawImage() not throw in this situation. It's simply not possible for me to guarantee that drawImage() always succeeds in a situation where we are very low on memory, but now we will silently draw nothing (which is more in line with the spec) rather than throw.

And please reopen this if bug 1162282 did not fix this. It sounds like the same fix should work for both cases, but without being certain where the exception is being thrown, I can't be sure that we aren't somehow failing earlier in the drawImage() code, before we get to the site which I fixed in bug 1162282.

Re-opening this bug per https://bugzilla.mozilla.org/show_bug.cgi?id=1163225#c5

Closing this again. The comment cited above is just showing that bug 1161734 is still a bug. It doesn't have anything to do with this. It appears to me that Seth is correct and his patch does prevent the "Component not available" error message that this bug is about. Unfortunately, we can now get completely black thumbnails when image memory is low. But that is a topic for 1163225