Created attachment 8346927 [details] MMSlockup.mp4 Description: If a user tries to send a MMS on a slow network connection, the phone will stop responding to touch. The lock button and home button will also stop working. The user will have to remove their battery to turn off the phone. Repro Steps: 1) Updated Buri/Inari/Leo/Unagi to Build ID: 20131212004004 2) Ensure the user is on a very slow network connection and tap on the "SMS app" icon. 3) Tap on the "Compose new SMS" icon. 4) Enter in a valid phone number into the "To" field. 5) Tap on the "Paperclip and tap on "Video". 6) Tap on a video to attach it to the SMS and then tap "Send". 7) While the MMS is sending try touching the screen and also try locking the phone. 8) If the phone is still responsive, attach another video to the same MMS and send it while the other one sending. Actual: The phone will become unresponsive to all input. The user cannot even lock the phone using the top button on the buri or go home the device. The user will have to remove their battery. Expected: The user does not lose functionality from sending a MMS on a slow network. Environmental Variables Device: Buri v 1.2.0 COM RIL Build ID: 20131212004004 Gecko: http://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/8bae10bb0aed Gaia: 6d02039072a2ae5cf9225a6f4c78ed49decfab5c Platform Version: 26.0 RIL Version: 01.02.00.019.102 Notes: Repro frequency: 100% See attached: video clip, logcat
Step 1 should state 1. Updated Buri to Build ID: 20131212004004
This issue could not be reproduced on Buri v 1.1.0 COM RIL Environmental Variables Device: Buri v 1.1.0 COM RIL Build ID: 20131210041202 Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/05117f42088f Gaia: 6ff3a607f873320d00cb036fa76117f6fadd010f Platform Version: 18.1 RIL Version: 01.01.00.019.281 The user did not lose phone functionality from sending multiple MMS on a slow network connection.
Keywords: regression, regressionwindow-wanted
Please note that i could only reproduce this with data turned on and WiFi turned on. WiFi barely had a connection as in one signal bar. Cell Data had no signal bar showing. I could not reproduce this issue with having WiFi Turned off and data having only one signal bar.
This sounds terrible, even if the use case is rare.
blocking-b2g: --- → koi?
I'd say this is more a RIL issue here. Could this be a Comm RIL issue only? Can you test with MozRIL ?
Component: Gaia::SMS → RIL
QA Wanted to check if this reproduces on the Moz RIL.
Keywords: regressionwindow-wanted → qawanted
This issue only reproduces on the Com RIL. We tried multiple times on Moz RIL but were unsuccessful in reproducing the issue. Gaia 1aca7c4860e39b1a9969807d335dcf9f070ea9b3 SourceStamp a2b69b561d9b BuildID 20131213004002 Version 26.0
mvines - Is this issue known?
blocking-b2g: koi? → ---
Component: RIL → Vendcom
Flags: needinfo?(ktucker) → needinfo?(mvines)
Not sure, old ril + new gecko/gaia = PORB (part of random build ;))
Hi Michael, 01.02.00.019.102 would be an old RIL for 1.2? Is there a location where we can download the latest ril?
Yes, .102 is quite old (early Nov). Currently no location for newer ones though, sry.
Thanks for the info. Please let us know when the next version is released. Otherwise our tests will be invalid. :(
Issue seems to occur on Buri V 1.3.0 Here are the environmental variables Environmental Variables Device: Buri v 1.3.0 COM RIL Build ID: 20131216004002 Gecko: http://hg.mozilla.org/releases/mozilla-aurora/rev/2ec5a40f544e Gaia: 1752e9e8f2b84b9db5d96ae5940596957fc8ed6c Platform Version: 28.0a2 RIL Version: 01.02.00.019.102
Whiteboard: [fxos-bug-bash-1.2] → [fxos-bug-bash-1.2][perf-reviewed]
Created attachment 8365231 [details] log.txt Was getting this issue last night on Buri 1.3 Moz. Here's the variables- Environmental Variables Device: Buri v 1.3.0 MOZ Build ID: 20140121004137 Gecko: http://hg.mozilla.org/releases/mozilla-aurora/rev/6f7dfe36ab6c Gaia: 47049555282a9a01fb60d1e1421b57e2810c96f5 Platform Version: 28.0a2 Firmware Version: V1.2-device.cfg attaching a logcat of an attempt to get this issue to occur, phone froze up slightly during this attempt, but did not completely lock.
To be clear here is the STR that I used to get this issue to reproduce. 1. Updated Buri to Build ID: 20140121004137. 2. Open the messaging app. 3. Tap on a short code number to reply. (a message from an automated source.) 4. Attach a picture message and tap send to reply. Actual: Phone locks up to varying degrees, message takes an extraordinarily long amount of time to send. Expected: Phone sends message and does not lock up. NOTES: When I first got this issue to reproduce last night I had to remove my battery to fix the issue, as no other method would end the lock up. If the message fails to send and the user retries to send the media, the phone will suffer noticeable slowdowns until the message is sent.
Milan, can you please check whether the log in attachment 8365231 [details] shows up some graphic-related issue?
Could be two different bugs; the new log shows us using the graphics memory to exhaustion, and falling to system memory. Previously, the graphics operations would just fail, so a lock up may have been an end result of that, in the December version. With the latest version, and message taking a long time, it really sounds like bug 962142, and it fits into the "regressed on Jan 18th" time frame.
Yeah, right, I agree these are probably different bugs since the first one was vendor-related. But how the graphics memory could be hogged? The spinner animation?
We use canvas whenever we need to send an image blob out.
Firefox OS is not being worked on
Status: NEW → RESOLVED
Last Resolved: 5 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.