Device: Flame Build: v2.0 with kk v180 (gecko-2d2ca12 gaia-7edd3b0) Loop version: c28eaef STR 1. Establish a GSM call between two devices (Device A and Device B). Device A calls Device B 2. From a device C, try to establish a loop call with Device B ACTUAL RESULT The attention screen shown is wrong and is not possible to answer the loop call (See attachment)

Fix the root cause of this bug on bug 1069847 (FYI pretty related root cause).

Tested again, and it's still happening. Device: Flame Build: v2.0 with kk v180 (Gecko-9362b48.Gaia-263e3b2) Loop version: 041ff17

Waiting some seconds (to answer de call), or if GSM call is on hold, It works fine.

.... E/GeckoConsole( 3286): Content JS LOG at app://loop.services.mozilla.com/call_screen/js/call_screen_ui.js:83 in CallScreenUI.init/<: An error occured! Permission Denied ...

(In reply to Javier de Prado from comment #4) > Created attachment 8494423 [details] > bug1069793.txt > > .... > E/GeckoConsole( 3286): Content JS LOG at > app://loop.services.mozilla.com/call_screen/js/call_screen_ui.js:83 in > CallScreenUI.init/<: An error occured! Permission Denied > ... Actually the issue is because a race condition while setting the call on hold. The message shown here, when failing at gUM, might not be correct (as it is happening in here).

The wrong call screen thing is fixed but we need to figure out why the gUM request fail when the GSM call is up. Change the bug name then.

and sometimes it appears and disappears this screen asking for the permissions

gUM fails with 'Permission Denied' error when It shouldn't as all the permission are granted. I've have seen the error is because a race condition as a 1-second-timeout fix solves the issue. Here you have that patch. Let's discuss a bit this and other possible solutions.

Comment on attachment 8494655 [details] Pointer to Github PR https://github.com/mozilla-b2g/firefoxos-loop-client/pull/131 Borja, I ended up with a solution which is to set the GSM call on hold earlier (by competing for audio) so gUM doesn't fail anymore. Have a look please. Thanks!

Comment on attachment 8494655 [details] Pointer to Github PR https://github.com/mozilla-b2g/firefoxos-loop-client/pull/131 Main thing is that it seems that there is no async. request in your code, so we should get rid of the promise. Take a look to the comments in GH and ask me to review this again when ready. Thanks!

Comment on attachment 8494655 [details] Pointer to Github PR https://github.com/mozilla-b2g/firefoxos-loop-client/pull/131 (In reply to Borja Salguero [:borjasalguero] from comment #10) > Comment on attachment 8494655 [details] > Pointer to Github PR > https://github.com/mozilla-b2g/firefoxos-loop-client/pull/131 > > Main thing is that it seems that there is no async. request in your code, so > we should get rid of the promise. Forget that patch please. > Take a look to the comments in GH and ask me to review this again when > ready. Thanks! Done, I took your suggestion and gave it a try. Seems to work. Javier, could you give a try and let us know if the patch fixes the issue on your side as well please? A double-check would be great.

Comment on attachment 8494655 [details] Pointer to Github PR https://github.com/mozilla-b2g/firefoxos-loop-client/pull/131 Borja, this is finally fixed. Both incoming and outgoings call. It was a matter of setting the GSM call on hold as earlier as possible. Now gUM doesn't fail and everything seems to work. Javier, just verify the patch when it lands.

Comment on attachment 8494655 [details] Pointer to Github PR https://github.com/mozilla-b2g/firefoxos-loop-client/pull/131 Please rebase and remove comments before merging. Thanks!

Landed at: https://github.com/mozilla-b2g/firefoxos-loop-client/commit/47ad47ff50be6838fc9511093317c65062ea8bf2

Loop Version 1.1: e4ffbba FireE: firee-kk-v2.0-SW2E5-4

Closing this bug as this issue was already resolved and new bug 1091790, with the specific problem was opened to track the issue found in the regression test.