Device: Flame Version: 2.2.0.0-prerelease (20141002160204) Steps to reproduce: 1. Go to Settings -> Sound. 2. Set Vibrate to ON. 3. Ask somebody to call you. 4. Answer the call. Actual results: Once the call is been answered, the phone continue to vibrate, even when you hung up the call. Expected results: Vibrations should stop as soon as the call is answered, or refused.

Seen the same thing yesterday. Gaia-Rev 0e280591881d44b80f456bc27e12d9114c218868 Gecko-Rev https://hg.mozilla.org/mozilla-central/rev/14665b1de5ee Build-ID 20141001040205 Version 35.0a1 Device-Name flame FW-Release 4.4.2 FW-Incremental 27 FW-Date Thu Sep 4 14:59:02 CST 2014 Bootloader L1TC10011800

Thanks again for filing a bug! I can't repro on today's build. Gaia-Rev d711d1e469eeeecf25a02b2407a542a598918b2c Gecko-Rev https://hg.mozilla.org/mozilla-central/rev/b85c260821ab Build-ID 20141003040207 Version 35.0a1 Device-Name flame FW-Release 4.4.2 FW-Incremental eng.jlorenzo.20141002.104456 FW-Date Thu Oct 2 10:45:09 CEST 2014 Bootloader L1TC10011800 Can you check if you're able to reproduce on a more recent build?

I update later today and try to reproduce.

I juste upgrade to Build-ID 20141003040207, and I cannot reproduce ! Thank you (cause that bug was a nightmare all day:))

I'm moving to Gaia::System as this is unlikely to be a dialer problem. Though it could also be a device API problem.

I'm seeing this on a master build from this morning. I received a call, answered it, and then the caller at the other end hung up after a few seconds. (It was my test incoming call after updating my phone; I'd already done a test outgoing call.) Then the phone just kept vibrating. It keeps vibrating until I turn the screen off, but then starts again if I turn the screen on again. gaia 83f495a1c12687970f7f2840c2729795c4b88177 gecko https://hg.mozilla.org/mozilla-central/rev/388e101e75c8 plus my patch queue

Not surprisingly, the mozilla::dom::Navigator::Vibrate calls are coming from: https://github.com/mozilla-b2g/gaia/blob/bec039ddfdf8d1547e0003595ccff00de9a71a5d/apps/system/js/dialer_agent.js#L194

Steps to reproduce (reliable for me): 1. have the cellphone unlocked, showing the homescreen 2. place a call to the cellphone from another phone 3. wait for the cell phone to start vibrating 4. hang up the other phone The cellphone keeps vibrating. (If I do the above twice, it vibrates more often!) (There may well be other combinations, but this one uses fewer cellphone minutes, I think.)

I also see this roday

dialer_agent.js is part of Dialer, moving back in this component

Let's get some branch checks on this.

I am unable to repro the bug on Flame 2.2 (engineering, nightly shallow flash and nightly full flash), Flame 2.1 or Flame 2.0 using shallow flash. Actual result: After following the STR on comment 8, the device stops vibrating once the call is terminated. The device does buzz a couple of times when the notification appears, but it's otherwise still. Flame 2.2 BuildID: 20141006064312 Gaia: 470826d13ae130a5c3d572d1029e595105485fb0 Gecko: e0d9ad4be606 Platform Version: 35.0a1 Firmware Version: V180 User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0 Nightly BuildID: 20141006040204 Gaia: 470826d13ae130a5c3d572d1029e595105485fb0 Gecko: e0d714f43edc Gonk: 2c909e821d107d414f851e267dedcd7aae2cebf Platform Version: 35.0a1 Firmware Version: V180 User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0 Flame 2.1 BuildID: 20141006062615 Gaia: 778ebac47554e1c4b7e9a952d73e850f58123914 Gecko: bc87917b3b95 Platform Version: 34.0a2 Firmware Version: V180 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Flame 2.0 BuildID: 20141006044157 Gaia: 26670a3193b57ead978ef2faefc2a679ea57f8d4 Gecko: c06b369ccda7 Platform Version: 32.0 Firmware Version: V180 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 Leaving qawanted tag for someone else to attempt.

I was also unable to reproduce this issue on Flame 2.2 KK, Flame 2.1 KK, or Flame 2.0 KK using shallow flash. Environmental Variables: Device: Flame 2.2 BuildID: 20141006141218 Gaia: 83de447d9ae9a59459d7a445f9348a254c661850 Gecko: eaa80e4597a2 Version: 35.0a1 (2.2) Firmware Version: L1TC10011800 User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0 Environmental Variables: Device: Flame 2.1 BuildID: 20141006121722 Gaia: aa2b95701d23c3d2f5958896f50c1fcebca98c5f Gecko: 2e2c194a54f5 Version: 34.0a2 (2.1) Firmware Version: L1TC10011800 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Environmental Variables: Device: Flame 2.0 BuildID: 20141006131113 Gaia: 26670a3193b57ead978ef2faefc2a679ea57f8d4 Gecko: 98b6b718ae2a Version: 32.0 (2.0) Firmware Version: L1TC10011800 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 Leaving the qawanted tag so another can attempt.

Hi guys! I hope this does not add noise to the discussion but helps someone :) When investigating bug 1066874 and just some minutes ago, I was able to reproduce this bug (the vibration one). In my case, you'll have to hang up the call from the calling phone and take it from the DuT almost at the same time. Bad (or maybe good) news is that after somes time restarting the phone I am not able to reproduce the vibration issue any longer (seems to be a very precise timing issue). :( Anyhow, when it did reproduce, I saw this on the console: “W/GeckoConsole( 1612): [JavaScript Error: "InvalidStateError: An attempt was made to use an object that is not, or is no longer, usable" {file: "app://system.gaiamobile.org/js/dialer_agent.js" line: 210” Hope that helps ;)

I just reproduced the vibration issue again after a lot of times not being able to (hanging and taking the call almost at the same time). So for me the repro rate is really low (and unstable). Happily, I get the same message on the console which I hope it will help track the issue down: “W/GeckoConsole( 1612): [JavaScript Error: "InvalidStateError: An attempt was made to use an object that is not, or is no longer, usable" {file: "app://system.gaiamobile.org/js/dialer_agent.js" line: 210”

Can any of the parties that CAN repro this bug please list what device they are using.

This definitely has happened to me on the Flame device, but happens intermittently. See the duped bug for the last build I saw it on.

I suspect that v2.1 and v2.0 are affected by this. I'm able to repro on v2.2 now. Here are my new STR: 1) Make sure your ringtone isn't working. This is the crux of the problem, but I don't know why mine isn't working. 2) Call the device. 3) Let the call linger without answering. Wait until it times out. 4) Observe it continue to vibrate. In app-manager, I get the following notice about half-way through the ringing process: Media resource blob:app://system.gaiamobile.org/68fba2b2-8d58-47a9-9d8d-8a6171957824 could not be decoded. Then when the call ends and it continues vibrating, I get the same error as Germán in comment 14.

PR: https://github.com/mozilla-b2g/gaia/pull/24909 While I can confirm that this fixes the issue, I'm still somewhat puzzled by why we have to do it to begin with. According to the HTMLMediaElement docs [1], we should only need HAVE_METADATA, as we were checking for before, for this to work correctly. Since Paul is on PTO, I think it's best if we go ahead with this for now and then get his input when he comes back.

Comment on attachment 8501409 [details] [diff] [review] Only seek ringtone back to start on ringtone if the file is loaded fully enough to seek. Review of attachment 8501409 [details] [diff] [review]: ----------------------------------------------------------------- I agree. Let's move forward with this and make sure we eventually understand what was the issue here.

qawanted for branch checks.

RE-branch check based on STR from comment 19

(In reply to Doug Sherk (:drs) from comment #19) > 1) Make sure your ringtone isn't working. This is the crux of the problem, > but I don't know why mine isn't working. Unfortunately, I can't really clarify this. I don't think there's any action required here, but I noticed that my ringtone wasn't working. Someone else was able to repro this while their ringtone worked. YMMV. I think the important part is step 3.

(In reply to Joshua Mitchell [:Joshua_M] from comment #23) > RE-branch check based on STR from comment 19 Able to reproduce the issue on Flame 2.2. Observed: Following STR on comment 19 (except step 1), DUT keeps vibrating until reboot. I also noticed that the ringtone doesn't repeat itself after it's done playing once. Repro rate: 3/3. Device: Flame (shallow flash) BuildID: 20141008065408 Gaia: 2665e714beea5dc433862ca6bb8d2b47ffe2f2d1 Gecko: 4bad24a306b2 Version: 35.0a1 (2.2 Master) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0 -------- Issue is NOT reproducible on Flame 2.1 and Flame 2.0. Following comment 19's STR except step 1, DUT does NOT keep vibrating after caller hangs up. Repro rate: 0/4 on v2.1, 0/3 on v2.0. Device: Flame (shallow flash) BuildID: 20141008092809 Gaia: 55ce3612bd8a8665139d6b85114ce59993a3fa0a Gecko: b0dce6c46c52 Version: 34.0a2 (2.1) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Device: Flame (shallow flash) BuildID: 20141008105706 Gaia: 94638b51a5a5d513e26247e9b207aa54e7bb0568 Gecko: bc9e3fa37e63 Version: 32.0 (2.0) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

We already have a patch that works around this, but knowing what regressed it would be really helpful, so we can fix it properly.

mozilla-inbound regression window: Last Working Environmental Variables: Device: Flame BuildID: 20140926154139 Gaia: e30d373eb5ed0514bce08a3b3d80d71b05a4dc32 Gecko: 627e848b2bf3 Version: 35.0a1 (2.2 Master) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0 First Broken Environmental Variables: Device: Flame BuildID: 20140926162338 Gaia: e30d373eb5ed0514bce08a3b3d80d71b05a4dc32 Gecko: 8892214038df Version: 35.0a1 (2.2 Master) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0 Gaia is the same so it's a Gecko issue. Gecko pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=627e848b2bf3&tochange=8892214038df Caused by Bug 994190.

(In reply to Doug Sherk (:drs) from comment #26) > We already have a patch that works around this, but knowing what regressed > it would be really helpful, so we can fix it properly. Broken by Bug 994190

Filed bug 1080298 for fixing this properly. https://github.com/mozilla-b2g/gaia/commit/f0a82790afad5564e0ada9ab321b1b2896e72e57

removing blocking flag as it's fixed on master which will be future 2.2

Backed out in https://github.com/mozilla-b2g/gaia/commit/bc8be5081676ffed4cf9c2c9c53fc48caa0f1a49 I don't think that there's any decent workaround for this. We will need the fallout from bug 994190 to be fixed correctly.

[Blocking Requested - why for this release]:

I believe I fixed this in bug 1076975.

It still seems like Gaia should be more resilient here.

Actually, it looks like it's fixed for me.

Agree. Let's dupe to 1076975. Any gaia followup can be cloned.