This bug was filed from the Socorro interface and is report bp-6f9149bb-3df6-446b-b064-ccd492150815. ============================================================= STR: 1. Make sure Settings -> Customize -> Tabs is set to "Always restore" 2. I've mostly tested with Allow autoplay enabled, although I've experienced the crash even with it disabled. 2. Open a local MP3 file from your device (like e.g. /storage/extSdCard/Music/SomeRandomFile.mp3) 3. Switch away from Firefox and kill the process by swiping it away in the task switcher. 4. Start Firefox again. Outcome: Session restore will restore your tabs, including the one containing the local MP3 file. Because the tab with the MP3 file is the currently selected tab, Firefox will start actually loading the MP3 file. Often (but not always), Firefox will crash during loading of that tab. Additional remarks: - If you open an additional tab and make it the active tab before switching away from Firefox, session restore will start restoring that tab instead, and leave the tab containing the MP3 file in the pending state. If you then switch to the MP3 tab, it will usually load normally without crashing Firefox, although somehow one time only I managed to crash Firefox that way, too. - Using an MP3 file from the Internet doesn't crash Firefox, so maybe it's some sort of race condition which is exposed because loading a file from your device is much faster than loading it from the internet. Test setup: Samsung Galaxy S3 Mini, Android 4.1.2 current Nightly (build 20150815030208) I've also tested on 41.0b1 with the same results, see e.g. bp-6240f6b4-e2de-4c11-ae11-5fdd32150815 On the current release version (FF40), the same STR are also crashing Firefox, but with two differences: 1. Crashing happens more reliably. This also means that this problem can cause a crash loop which can only be broken by deleting your sessionstore.js. 2. A different crash signature: [@ nsObserverService::AddObserver(nsIObserver*, char const*, bool)] See bp-545c0c66-65e6-4eed-858e-b5d632150815 for an exemplary crash report.
I don't know in how far that's related to the root cause of the above crashes, or if it should belong in a different bug, but I've noticed some crashes which, as far as I can discern, follow the general pattern of: - I interact with some MP3 file, either by opening it directly, or via page with an HTML5 audio player - I stop playback and close the tab. However because so far I haven't found a reliable way to reproduce these crashes, I can't remember whether I first stopped playback and then closed the tab, or whether I closed the tab directly, and also if I closed the tab at all in all cases. - Some time later, Firefox crashes with a crash in libsomxcore.so@0x1826.
Component: Audio/Video → Audio/Video: Playback
tracking-fennec: --- → ?
Assignee: nobody → esawin
tracking-fennec: ? → 44+
Component: Audio/Video: Playback → Audio/Video
Product: Core → Firefox for Android
Is this a duplicate of another bug?
(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #3) > Is this a duplicate of another bug? Unclear, I can't reproduce it on the device. Jan, can you still reproduce it on Nightly?
Flags: needinfo?(esawin) → needinfo?(jh+bugzilla)
No, I cannot reproduce it either. I think I managed one crash out of more than ten attempts on the current release version (44.0), but I don't know whether that signifies something or whether it simply happened by chance and could have equally happened on Nightly. In any case I guess I can close this issue on that basis.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.