Could you help us here? Thanks!
blocking-b2g: --- → leo?
Severity: normal → critical
Line 1246 is just a call to getDeviceStorage(). (It is in an unusual place, though, indicating that you have unscanned photos on your sdcard, and that the photos do not have large enough EXIF preview images. If you run gallery and let it scan everything first, then this crash should go away. Obviously though, we need to figure out why the crash is happening. I can't duplicate this, even with an unscanned previewless image on the device. Are you using a Leo device, or some other device that has both internal and external device storage? My guess is that this is related to the new device storage stuff, so I'm setting needinfo on dhylands. Given that the failure is in a call to getDeviceStorage(), however, I wonder if there is something happening with permissions?
FTR I got it too with unagi. But I had a fairly old (about 1 week) b2g18 gecko, I didn't try again since I updated.
Given the changes to device storage over the last couple of weeks, you might try re-testing this after blowing away your gallery database (or after reset-gaia) adb shell rm -r /data/local/indexedDB/*gallery* Its possible that the device storage changes just mean that gallery is broken on devices that have two storage areas (or have photos in two storage areas). dhylands has pending bugs to update mediadb and/or gallery for the new device storage stuff, so he should know.
I think that it's unusual for navigator.getDeviceStorage('pictures') to fail at all. Looking through the code, there appears to be only one code path which can cause NS_ERROR_FAILURE (same on master and b2g18): https://mxr.mozilla.org/mozilla-central/source/dom/base/Navigator.cpp#995 which seems to imply one of the following conditions: no window, no outer window, or no docshell I'm not sure exactly how these particular things translate back into gaia.
Maybe the scanning process was continuing after the pick was complete and there was a brief period where the gallery (running as an activity) code was still running but its window (or whatever) had been destroyed. Borja and Julien: did this happen after you picked and cropped the image and were returning to the MMS app? Was there actually a crash or just a message in logcat? Did the image pick complete successfully? How reproducible is it? (i.e is it a rare race condition, or something that happens all the time?)
It happened several times so it was not rare. I think I actually tried to crop the image. I'll try more today.
Hi, I add Borja's feedback since he is OOO today: gecko: mozilla central gaia: master device: Unagi did this happen after you picked and cropped the image and were returning to the MMS app? >>>It happens after picking and cropping the image and returning to the MMS app when cliking on "Send" button Was there actually a crash or just a message in logcat? >>>There is a crash, Unagi device is automatically rebooted Did the image pick complete successfully? >>>Yes How reproducible is it? (i.e is it a rare race condition, or something that happens all the time?) >>>100% reproducible, even after executing: adb shell rm -r /data/local/indexedDB/*gallery*
Hi, it seems that (after talking with Julien) MMS development team is using gecko:b2g18 so using latest version of gecko: b2g18 gaia: master device: Unagi I am not reproducing the crash and I am sending and receiving the MMS succesfully. Anyway, as Noemi has said, the fault is happening in master branch with gecko pointing to mozilla-central.
I don't reproduce it with current master/b2g18 either. I tried cloberring my indexeddb but it still worked.
Not reproducible, and only can do on m-c Gecko, which is not supported. Resolved->INVALID. Re-open if reproducible on b2g18 Gecko still.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INVALID
please re-nominate if this reproduces
blocking-b2g: leo? → ---
You need to log in before you can comment on or make changes to this bug.