1069500 - [Loop][Regression] Can't receive calls with 2.2

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect)

Description

[Fernando Jiménez Moreno [:ferjm]]

Attachment: Screenshot

We can't receive calls anymore on a 2.2 build. It seems that the gUM permission dialog appears for a very short time on top of the call screen and then it disappears leaving the call screen blocked and with the layout shown in the attached screenshot.

Comment 1

[Maria Angeles Oteo (:oteo)]

Fernando,I'm not sue but perhaps bug 1065720 could be related...

Comment 2

[Fernando Jiménez Moreno [:ferjm]]

Yes, might be. There's something wrong with the window manager on 2.1, but might be something else. This is definitely not a Loop issue cause this works fine on 2.0.

Comment 3

[KTucker [:KTucker][Inactive 3/4/2016]]

Adding qawanted for branch checks.

Comment 4

[Chris Kreinbring [:CKreinbring]]

The bug repros on Flame 2.2 and Flame 2.1 using shallow flash.
Actual result: With Loop version 83b17d9, attempting to answer a received call will terminate the call instead of starting it.  Afterwards an error page will appear (see screenshot).  Granting access to camera and microphone from Setting > App permissions will not cause this bug to repro anymore.

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

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

--------------------------------------------------------------------------------------------------------

The bug does not repro on Flame 2.0
Actual result: When receiving a call for the first time, a screen will appear asking for access permission to the device camera and microphone.  Granting it will allow the user to receive the call with no errors.

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

Comment 5

[Chris Kreinbring [:CKreinbring]]

Attachment: Screenshot of 2.2 and 2.1 error message

Comment 6

[Joshua Mitchell (Inactive)]

[Blocking Requested - why for this release]: This seems like a really bad issue - when using the Loop app the user will not be able to receive incoming calls.

Comment 7

[howie [:howie]]

Triage: regression. blocking.

Comment 8

[Etienne Segonzac (:etienne)]

(In reply to Chris Kreinbring [:CKreinbring] from comment #4)
> Granting access to camera and microphone
> from Setting > App permissions will not cause this bug to repro anymore.

Interesting. Can we QA this on a 2.0 gecko with a gaia master? Might be a platform issue.

Comment 9

[Chris Kreinbring [:CKreinbring]]

Regression window
Last working
BuildID: 20140829122301
Gaia: 007f3c50cf69f044628a23c2376c6d88aa45f617
Gecko: 9b3fbc370631
Platform Version: 34.0a1
Firmware Version: V123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

First broken
BuildID: 20140829123201
Gaia: c05ee27dd1f39e0f1cceb8bc7706e20f297cd9df
Gecko: 2a354048f964
Platform Version: 34.0a1
Firmware Version: V123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Working Gaia / Broken Gecko = No repro
Gaia: 007f3c50cf69f044628a23c2376c6d88aa45f617
Gecko: 2a354048f964
Broken Gaia / Working Gecko = Repro
Gaia: c05ee27dd1f39e0f1cceb8bc7706e20f297cd9df
Gecko: 9b3fbc370631
Gaia pushlog: https://github.com/mozilla-b2g/gaia/compare/007f3c50cf69f044628a23c2376c6d88aa45f617...c05ee27dd1f39e0f1cceb8bc7706e20f297cd9df


B2G Inbound
Last working
BuildID: 20140828211200
Gaia: 8d965e7182500fd1849e8eec5ae2aca35a55af22
Gecko: efb4f3f291a4
Platform Version: 34.0a1
Firmware Version: V123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

First broken
BuildID: 20140828223200
Gaia: 6f270b9fee0c1f09863f5e1aa640937a07c7fdae
Gecko: 18ed4643a705
Platform Version: 34.0a1
Firmware Version: V123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Working Gaia / Broken Gecko = No repro
Gaia: 8d965e7182500fd1849e8eec5ae2aca35a55af22
Gecko: 18ed4643a705
Broken Gaia / Working Gecko = Repro
Gaia: 6f270b9fee0c1f09863f5e1aa640937a07c7fdae
Gecko: efb4f3f291a4
Gaia pushlog: https://github.com/mozilla-b2g/gaia/compare/8d965e7182500fd1849e8eec5ae2aca35a55af22...6f270b9fee0c1f09863f5e1aa640937a07c7fdae

Comment 10

[Joshua Mitchell (Inactive)]

Broken by Bug 927862 - can you take a look Alive?

Etienne - where you asking "Can we QA this on a 2.0 gecko with a gaia master? Might be a platform issue." to get a swap between a Gecko / Gaia and affected / unaffected branches to determine if it was a Gecko or a Gaia issue? If so then the regression window firmly shows it is a GAIA issue. If I misunderstood the intent of the request please re-add the qa-wanted keyword if you need additional testing beside the regression window results.

Comment 11

[(inactive after 6/18) Alive Kuo [:alive]]

Attachment: https://github.com/mozilla-b2g/gaia/pull/24916

Honestly I dislike moving zindex of permission dialog; the long term solution should be to move it into the appWindow/attentionWindow who is requesting the permission so we don't need to care any permission z-ordering anymore.
But let's do this for a blocker.

Comment 12

[Etienne Segonzac (:etienne)]

Comment on attachment 8501533 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/24916

I was afraid of the implications regarding permission prompts on top of the lockscreen, but the lockscreen is already below on master.

Comment 13

[Fernando Jiménez Moreno [:ferjm]]

Comment on attachment 8501533 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/24916

Thanks for the patch Alive. I am afraid that it doesn't solve the issue. I still can see the permission dialog appearing for a moment but the attention screen makes it go away as soon as it is shown in the screen.
If you want to test with Loop you can install it by following these steps https://wiki.mozilla.org/Loop/Try_Loop#Firefox_OS_Loop_Client
Thanks!

Comment 14

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Fernando Jiménez Moreno [:ferjm] from comment #13)
> Comment on attachment 8501533 [details] [review]
> https://github.com/mozilla-b2g/gaia/pull/24916
> 
> Thanks for the patch Alive. I am afraid that it doesn't solve the issue. I
> still can see the permission dialog appearing for a moment but the attention
> screen makes it go away as soon as it is shown in the screen.
> If you want to test with Loop you can install it by following these steps
> https://wiki.mozilla.org/Loop/Try_Loop#Firefox_OS_Loop_Client
> Thanks!

This sounds https://github.com/mozilla-b2g/gaia/commit/81bb995b0b619d7aa4c65fcac7a307806acb1f99 from bug 1040406. Looks like the permission request is fired "before" the attention window is opened.

So I want to know who is requesting the permission? Is it the attention page or the index page at background?

Comment 15

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 8501533 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/24916

Updated:
The problem is the attention window is not opened before the permission request fired; we should not dismiss the permission prompt if it's coming from the attention window.

Comment 16

[Fernando Jiménez Moreno [:ferjm]]

Thanks Alive!

The updated patch solves the issue for incoming calls. However I still see the following:

1. The call screen still shows the "Firefox Hello call in progress" bottom green banner. 
2. Outgoing calls still have the same issue. The permission screen is shown for a moment and the the attention screen kills the permission one. This may be happening cause we call gUM before opening the attention screen at https://github.com/mozilla-b2g/firefoxos-loop-client/blob/master/js/helpers/call_screen_manager.js#L24

Both might be Loop issues that are not happening on 2.0, but I don't really have the time to look deeper into this right now. Maybe Carmen or Cristian can take a look.

Comment 17

[Etienne Segonzac (:etienne)]

Comment on attachment 8501533 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/24916

I don't think we can change it much further for 2.1. We might want to tweak when we call |window.open| from the loop client (with regards to the permission prompts).

I'll also file a follow up to get more marionette coverage on the permission prompt + attention screen behaviors.

Comment 18

[Cristian Rodriguez (:crdlc)]

Fernando, at least this week, I don't have a chance to take a look at that

Comment 19

[Carmen Jimenez Cabezas]

Fernando, as Cristian said I also don't have time to check it this week

Comment 20

[Cristian Rodriguez (:crdlc)]

If wouldn't have blockers or high priority bugs next week (Monday day off) I could take a look at this Fernando

Comment 21

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Fernando Jiménez Moreno [:ferjm] from comment #16)
> Thanks Alive!
> 
> The updated patch solves the issue for incoming calls. However I still see
> the following:
> 
> 1. The call screen still shows the "Firefox Hello call in progress" bottom
> green banner. 

I believe this is a bug of loop. You should update the banner in 'resize' handler.

> 2. Outgoing calls still have the same issue. The permission screen is shown
> for a moment and the the attention screen kills the permission one. This may
> be happening cause we call gUM before opening the attention screen at
> https://github.com/mozilla-b2g/firefoxos-loop-client/blob/master/js/helpers/
> call_screen_manager.js#L24
> 

Haven't check, maybe we need another bug for this?

Comment 22

[(inactive after 6/18) Alive Kuo [:alive]]

tbpl all green,
https://github.com/mozilla-b2g/gaia/commit/36c0fc084eda16cd6a1755de0d73635406d79a73

Comment 23

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 8501533 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/24916

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #):
Bug 1040406
[User impact] if declined:
User is not able to recieve loop incoming call if the webrtc permission is not default granted.
[Testing completed]: yes
[Risk to taking this patch] (and alternatives if risky): riskless
[String changes made]: no

Comment 24

[Fernando Jiménez Moreno [:ferjm]]

Thanks Alive. I filed bug 1082519 and bug 1082517 as follow ups

Comment 25

[Ryan VanderMeulen [:RyanVM]]

v2.1: https://github.com/mozilla-b2g/gaia/commit/0ecaa0d48a05e731b7e083aa6d8a94199a082c8e

Comment 26

[Yeojin Chung [:YeojinC]]

This issue is verified fixed on Flame 2.2 and 2.1.
I was able to make and receive calls after granting the access.

Flame 2.2 

Device: Flame 2.2 Master (319mb)(Kitkat Base)(Full Flash)
BuildID: 20141023040204
Gaia: 27a1d1baaa8e375b70e043efee67d5f2206c330b
Gecko: 88adcf8fef83
Gonk: 05aa7b98d3f891b334031dc710d48d0d6b82ec1d
Version: 36.0a1 (2.2 Master)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0


Flame 2.1 

Device: Flame 2.1 (319mb)(Kitkat Base)(Full Flash)
BuildID: 20141023001201
Gaia: 1e48e3e40e0780c0cd07a3457e5fe2efeeb542d1
Gecko: 09fb60a37850
Gonk: 05aa7b98d3f891b334031dc710d48d0d6b82ec1d
Version: 34.0 (2.1)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0