1091790 - When a GSM call is established, as soon a Loop call enters and try to be answered is ended, cause by gUM fails.

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Loop, defect)

Description

[Maria Angeles Oteo (:oteo)]

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

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
3. Device B answer the Loop Call (through audio or video buttons)

ACTUAL RESULT
Loop call is directly ended on both sides (devices C and B)

Expected
Loop call is established between devices C and B while the GSM is on hold

Comment 1

[Maria Angeles Oteo (:oteo)]

[Blocking Requested - why for this release]:Critical Bug for Loop MObile Client.
This functionality was working as expected until last Sunday, 26 Oct)

We suspect that it could be a regression after landing in 2.0 the platform Bug 1077190.

Comment 2

[José Antonio Olivera Ortega [:jaoo]]

See https://bugzilla.mozilla.org/show_bug.cgi?id=1077190#c68 please.

Comment 3

[Jay]

Joes, Maria,
Does it work after reverting Bug 1077190?

Comment 4

[José Antonio Olivera Ortega [:jaoo]]

(In reply to Jay from comment #3)
> Does it work after reverting Bug 1077190?

Yes, it does.

We have kind of CI environment and we have new builds daily. Last working build was v2.0.Gecko-1f9f165.Gaia-86d83f4, first failing build was v2.0.Gecko-e4e58d7.Gaia-a2719af. Bug 1077190 was landed in between. Note this change landed on the Moz reference RIL implementation. Bug reported here reproduces as well on a build running the QC RIL implementation (the one shared by TCL for the FireE device). Sadly there is no way to let you know whether it is regression on the QC RIL implementation.

Comment 5

[:shell escalante]

Hi, it looks like there is a regression potentially from Bug 1077190.  Any thoughts?

Comment 6

[Wesly Huang (EPM)]

[Triage] per discussion tag for 2.0, impact Loop which is important to TEF.

Hi Szu-Yu: would you help look into this one? Thank you.

Comment 7

[Szu-Yu Chen [:aknow] (inactive)]

(In reply to Wesly Huang from comment #6)
> [Triage] per discussion tag for 2.0, impact Loop which is important to TEF.
> 
> Hi Szu-Yu: would you help look into this one? Thank you.

It's caused by Bug 1077190. However, I cannot provide any comment on this. You may refer to Bug 1077190 Comment 69.

Comment 8

[Keven Kuo [:kkuo]]

Per discussion with Steven/Randy. NI Randy.

--
Keven

Comment 9

[Randy Lin [:rlin] - Be Mozillian on 2015/01/26]

Hi Jaoo, 
Do you know what cause the loop enter ended status directly?
I can reproduce it but I don't know what cause loop enter ended status on this case.

Comment 10

[José Antonio Olivera Ortega [:jaoo]]

(In reply to Randy Lin [:rlin] from comment #9)
> Hi Jaoo, 
> Do you know what cause the loop enter ended status directly?
> I can reproduce it but I don't know what cause loop enter ended status on
> this case.

The root cause of the webrtc call being terminated is because when the GSM call is held the phone status is still IN_COMMUNICATION and the webrtc call terminates (actually it terminates because the gUM -get user media- call fails). In the MOZ RIL implementation (before landing bug 1077190) the phone state was NORMAL when the GSM was held and the webrtc call was able to get established.

Comment 11

[Randy Lin [:rlin] - Be Mozillian on 2015/01/26]

When the GSM call is on, try to use gUM web test page and can't get media stream object.

Comment 12

[Randy Lin [:rlin] - Be Mozillian on 2015/01/26]

ni? Steven for can't get media stream from gUM on phone call case.

Comment 13

[José Antonio Olivera Ortega [:jaoo]]

(In reply to Randy Lin [:rlin] from comment #11)
> When the GSM call is on, try to use gUM web test page and can't get media
> stream object.

When a WebRTC call interrupts a GSM one, the GSM is set on hold. Even when the GSM is held the gUM function fails. Before landing patch from bug 1077190 the gUM function wasn't failing because phone state was NORMAL. What bug 1077190 changed is that phone state keeps IN_COMMUNICATION even if the GSM is held.

Comment 14

[José Antonio Olivera Ortega [:jaoo]]

(In reply to José Antonio Olivera Ortega [:jaoo] from comment #13)

Sorry I made a mistake when adding the last comment.

> (In reply to Randy Lin [:rlin] from comment #11)
> > When the GSM call is on, try to use gUM web test page and can't get media
> > stream object.
> 
> When a WebRTC call interrupts a GSM one, the GSM is set on hold. Even when
> the GSM is held the gUM function fails. Before landing patch from bug
> 1077190 the gUM function wasn't failing because phone state was NORMAL. What
> bug 1077190 changed is that phone state keeps IN_COMMUNICATION even if the
> GSM is held.

I'll rewrite what I said above.

When a WebRTC call interrupts a GSM one, the GSM is set on hold. Even when the GSM is held the gUM function fails. Before landing patch from bug 1077190 the gUM function wasn't failing because phone state was NORMAL. What bug 1077190 changed is that phone state keeps IN_CALL even if the GSM is held.

Comment 15

[StevenLee[:slee]]

I have problems when using loop app. I have 2 devices, login with FF account and cannot call each other. :(

I can reproduce the problem by 
1. holding a GSM call
2. go to http://mozilla.github.io/webrtc-landing/gum_test.html
3. (a) press video --> prompt permission dialog and gets video successfully
   (b) press audio --> DO NOT prompt permission dialog and fails
I'm not sure whether it's from the same cause.

Comment 16

[Daniel Coloma:dcoloma]

(In reply to StevenLee[:slee] from comment #15)
> I have problems when using loop app. I have 2 devices, login with FF account
> and cannot call each other. :(

Which is exactly the problem you are having to make the call?

Comment 17

[StevenLee[:slee]]

(In reply to Daniel Coloma:dcoloma from comment #16)
> (In reply to StevenLee[:slee] from comment #15)
> > I have problems when using loop app. I have 2 devices, login with FF account
> > and cannot call each other. :(
> Which is exactly the problem you are having to make the call?
I'm trying to reproduce the problem from comment 0. So that I need a device that is able to receive the loop call.

Comment 18

[Daniel Coloma:dcoloma]

(In reply to StevenLee[:slee] from comment #17)
> (In reply to Daniel Coloma:dcoloma from comment #16)
> > (In reply to StevenLee[:slee] from comment #15)
> > > I have problems when using loop app. I have 2 devices, login with FF account
> > > and cannot call each other. :(
> > Which is exactly the problem you are having to make the call?
> I'm trying to reproduce the problem from comment 0. So that I need a device
> that is able to receive the loop call.

Yes, I understand, but what are the steps you are following to make the Loop call and where is it failing?

Comment 19

[StevenLee[:slee]]

(In reply to Daniel Coloma:dcoloma from comment #18)
> Yes, I understand, but what are the steps you are following to make the Loop
> call and where is it failing?
1. open loop
2. login by FF account or phone number
3. call another device
4. the other device does not have any response and after some time the caller shows that the callee is not online.

Comment 20

[José Antonio Olivera Ortega [:jaoo]]

(In reply to StevenLee[:slee] from comment #19)
> (In reply to Daniel Coloma:dcoloma from comment #18)
> > Yes, I understand, but what are the steps you are following to make the Loop
> > call and where is it failing?
> 1. open loop
> 2. login by FF account or phone number
> 3. call another device
> 4. the other device does not have any response and after some time the
> caller shows that the callee is not online.

Logout and sign up again in the device not receiving the call. I'm on IRC [:jaoo] in case you need further help. Thanks!

Comment 21

[StevenLee[:slee]]

(In reply to José Antonio Olivera Ortega [:jaoo] PTO till 11/24 from comment #20)
> Logout and sign up again in the device not receiving the call. I'm on IRC
> [:jaoo] in case you need further help. Thanks!
re-login seems works on my devices, thanks.

Hi SC,

I found that when problem happens. MediaDeviceSuccessCallback::DoPrompt is called, but nsContentPermissionRequestProxy::Allow in parent side isn't. So that the app cannot get permission to get MediaStream. Can you give any hints about it?
Thanks.

Comment 22

[StevenLee[:slee]]

I think I should give some more details.
(In reply to StevenLee[:slee] from comment #21)
> Hi SC,
> 
> I found that when problem happens. MediaDeviceSuccessCallback::DoPrompt is
This is called from content side.
> called, but nsContentPermissionRequestProxy::Allow in parent side isn't. So
From the log that getUserMedia works correctly, after MediaDeviceSuccessCallback::DoPrompt is called from content side, nsContentPermissionRequestProxy::Allow will be called in parent process. Then it sends ipc messages carrying the permission information to content process. I'm not familiar with the mechanism of calling nsContentPermissionRequestProxy::Allow. SC, can you give some more information about it. Thanks.

Comment 23

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

Here is the whole picture of gUM permission on Firefox OS:

// content process
1. gUM is invoked, fires "getUserMedia:request" event via observer
2. MediaPermissionGonk catches the event and query the available devices (MediaPermissionManager::HandleRequest)
3. MediaPermissionGonk receives the device list and send permission request to chrome process. (MediaDeviceSuccessCallback::DoPrompt)

// chrome process
4. ContentPermissionRequestParent receives the permission request and try prompt to user. (nsContentPermissionRequestProxy::Init)
5. ContentPermissionPrompt.js check the permission table, and delegate the prompt request to Gaia via mozChromeEvent in necessary. (ContentPermissionPrompt.prompt)

// Gaia System App
6. display UI to user. (apps/system/js/permission_manager.js handlePermissionPrompt)
7. send back the user choice to Gecko via mozContentEvent. (apps/system/js/permission_manager.js dispatchResponse)

// chrome process
8. ContentPermissionPrompt.js receives the choices and trigger corresponding callback. (ContentPermissionPrompt.js delegatePrompt)
9. nsContentPermissionRequestProxy sends back user choice to content process via IPC. (nsContentPermissionRequestProxy::Allow / nsContentPermissionRequestProxy::Cancel)

// content process
10. RemotePermissionRequest receives user choice from IPC and invoke corresponding callback in MediaPermissionRequest. (RemotePermissionRequest::Recv__delete__)
11. MediaPermissionRequest fires "getUserMedia:response:allow" or "getUserMedia:response:deny" via observer. (MediaPermissionRequest::Allow / MediaPermissionRequest::Cancel)
12. MediaManager receives the event and continue the gUM procedure. (MediaManager::Observe)

Comment 24

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

Bug 918054 is the bug for denying gUM request during GSM call, related code in [1].

[1] http://dxr.mozilla.org/mozilla-central/source/b2g/components/ContentPermissionPrompt.js#456

Comment 25

[StevenLee[:slee]]

(In reply to Shih-Chiang Chien [:schien] (UTC+8) from comment #24)
> Bug 918054 is the bug for denying gUM request during GSM call, related code
> in [1].
> 
> [1]
> http://dxr.mozilla.org/mozilla-central/source/b2g/components/
> ContentPermissionPrompt.js#456
Hi SC,

Thanks for the information. After reverting the patch, gUM works correctly. 

From bug 918054, there are some privacy issues here. I cc'ed pauljt and rjesup here.

Comment 26

[José Antonio Olivera Ortega [:jaoo]]

(In reply to Shih-Chiang Chien [:schien] (UTC+8) from comment #24)
> Bug 918054 is the bug for denying gUM request during GSM call, related code
> in [1].
> 
> [1]
> http://dxr.mozilla.org/mozilla-central/source/b2g/components/
> ContentPermissionPrompt.js#456

Wow, I wasn't aware of that piece of code. Thanks for digging out this Shih-Chiang.

Comment 27

[Paul Theriault [:pauljt] (no longer reading bugmail)]

So the restriction was deliberate, so that getUserMedia can't be used by web pages to record phone calls. If this is product requirement contrary to this control, we need to make sure that user's phone calls can't accidentally be bugged. We might be able to relax this restriction now that notifications are implemented, and prompt is more stable. 

Considering the specific risk scenarios:

1. Website A is using the microphone then a phone call starts
This case is probably ok now, since the user should be aware that they started recording (since they accepted the prompt). Notification in tray also helps so the user doesn't forget they had microphone turned on.

2. On a phone call then a app/website requests access to the microphone
In this case, the user will get a prompt while the phone is up to their ear. I think prompts are modal (per app) so Im not sure that webrtc prompt will appear at all.

Loop is a special case since it doesn't need to prompt (treated as a certified app for permission purposes). But this means the responsibility will be on Loop to ensure that the answering of calls is intuitive, and doesn't expose the user. For example it would be really bad, if the user might accidentally answer the loop call with their ear. If you knew someone was on there phone, you could loop them, and hope they bump the answer button to snoop on the call. But I imagine the Loop ringer will mitigate this risk (and blow-up your ear drums :) 

So TLDR: since notification and prompts are working now and free from the bugs mentioned in bug 918054, I think its probably ok to relax this restriction. 

Note that this will make it possible make phone-call recording apps - there might be legal implications of this? Jishnu - any comments here?

Comment 28

[Jishnu Menon :jishnu]

Please open a separate legal bug and assign to Geoff Piper - thanks!

Comment 29

[Kai-Chih Hu [:khu]]

If we have a flow that allows users to approve the recording and we pass the legal issue, what technical parts we should work on? Only Gaia or we should also do something in Gecko to allow the permission control? Thanks.

Comment 30

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

We'll need to remove the code I mentioned in comment #24 to relax the restriction in gecko. I'm not sure if we can get the microphone for the incoming call while a website is using it, see Bug 940020.

Comment 31

[Keven Kuo [:kkuo]]

Hi! SC,

Could you help to remove the code of bug 918054? Thanks

--
Keven

Comment 32

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

Attachment: remove-permission-constraint.patch

Patch for removing the GSM call restriction.

Comment 33

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

I did some experiment last Friday and here are the steps:

1. establish GSM call between Flame and my cell phone.
2. establish WebRTC call (via AppRTC) between Flame and my desktop.

[result]
WebRTC call can be established successfully, however, both my cell phone and my desktop can hear the voice from Flame.

Apparently, this behavior is not the same with multiple GSM call behavior (one call will be on hold). I guess there will need some more code for microphone policy, ni? mreavy for continuing the UX/security discussion and arranging resource for the rest of engineering work.

Comment 34

[Randell Jesup [:jesup] (needinfo me)]

schien: is the patch a backout of the previous patch that caused this starting on Oct 26th?  Or is it a new patch to allow this for loop?  (I'm guessing the second for privacy reasons.)

What are the differences between what we're doing now (from a loop call) and what we did before Oct 26th?  Since apparently back then it did put the GSM call on hold...

Comment 35

[Maire Reavy [:mreavy]]

(In reply to Randell Jesup [:jesup] from comment #34)
> schien: is the patch a backout of the previous patch that caused this
> starting on Oct 26th?  Or is it a new patch to allow this for loop?  (I'm
> guessing the second for privacy reasons.)
> 
> What are the differences between what we're doing now (from a loop call) and
> what we did before Oct 26th?  Since apparently back then it did put the GSM
> call on hold...

Hi SC -- Randell's questions are very relevant to which teams I would reach out to.  As you say, this isn't really a WebRTC issue since calls work.  I'm thinking the right folks to hand this off to would be the Audio Channel folks (like :baku or someone on his team).

Comment 36

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

(In reply to Randell Jesup [:jesup] from comment #34)
> schien: is the patch a backout of the previous patch that caused this
> starting on Oct 26th?  Or is it a new patch to allow this for loop?  (I'm
> guessing the second for privacy reasons.)
> 
> What are the differences between what we're doing now (from a loop call) and
> what we did before Oct 26th?  Since apparently back then it did put the GSM
> call on hold...

This patch is definitely not a backout of bug 1077190.

I took a detailed look at those comments before my first ni? this morning. The actual issue we need to solve first is "how do we distinguish an active GSM in B2G process after bug 1077190". For Loop, what we should do is updating the statement [1] but not reverting all the changes in bug 918054.

@Aknow, can you point me out how to detect active GSM call in current code base? The code in [1] seems to out dated after bug 1077190 (cannot distinguish the call on held).

[1] https://dxr.mozilla.org/mozilla-central/source/b2g/components/ContentPermissionPrompt.js#458

Comment 37

[Szu-Yu Chen [:aknow] (inactive)]

(In reply to Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz) from comment #36)
> (In reply to Randell Jesup [:jesup] from comment #34)
> > schien: is the patch a backout of the previous patch that caused this
> > starting on Oct 26th?  Or is it a new patch to allow this for loop?  (I'm
> > guessing the second for privacy reasons.)
> > 
> > What are the differences between what we're doing now (from a loop call) and
> > what we did before Oct 26th?  Since apparently back then it did put the GSM
> > call on hold...
> 
> This patch is definitely not a backout of bug 1077190.
> 
> I took a detailed look at those comments before my first ni? this morning.
> The actual issue we need to solve first is "how do we distinguish an active
> GSM in B2G process after bug 1077190". For Loop, what we should do is
> updating the statement [1] but not reverting all the changes in bug 918054.
> 
> @Aknow, can you point me out how to detect active GSM call in current code
> base? The code in [1] seems to out dated after bug 1077190 (cannot
> distinguish the call on held).
> 
> [1]
> https://dxr.mozilla.org/mozilla-central/source/b2g/components/
> ContentPermissionPrompt.js#458

There is no simple way to do it now. You will need to enumerate all calls through TelephonyService and then check the state of each call.

Here are the related interfaces and methods.

https://dxr.mozilla.org/mozilla-central/source/dom/telephony/nsITelephonyService.idl
https://dxr.mozilla.org/mozilla-central/source/dom/telephony/nsITelephonyCallInfo.idl

interface nsITelephonyListener : nsISupports
{
  /**
   * Called when enumeration asked by nsITelephonyService::enumerateCalls
   * is completed.
   */
  void enumerateCallStateComplete();

  /**
   * Called when nsITelephonyService is asked to enumerate the current
   * telephony call state (nsITelephonyService::enumerateCalls). This is
   * called once per call that is currently managed by the RIL.
   */
  void enumerateCallState(in nsITelephonyCallInfo info);
};

interface nsITelephonyService : nsISupports
{
  const unsigned short CALL_STATE_CONNECTED = 4;

  /**
   * Will continue calling listener.enumerateCallState until the listener
   * returns false.
   */
  void enumerateCalls(in nsITelephonyListener listener);
};

interface nsITelephonyCallInfo : nsISupports
{
  /**
   * One of the nsITelephonyService::CALL_STATE_* values.
   */
  readonly attribute unsigned short callState;
};


Step 1. Get the TelephonyService

  XPCOMUtils.defineLazyServiceGetter(this, "TelephonyService",
                                    "@mozilla.org/telephony/telephonyservice;1",
                                    "nsITelephonyService");

Step 2. Create your own object that implements nsITelephonyService. Note that the following two methods will be called.

  void enumerateCallStateComplete();
  void enumerateCallState(in nsITelephonyCallInfo info);

Step 3. Enumerate the calls

  TelephonyService.enumerateCalls(listener)

Step 4. Collect the call info

  Each call triggers one nsITelephonyListener.enumerateCallState() and enumerateCallStateComplete() is used to signal the end of the enumeration.

Step 5. Check whether there is a call with 'connected' call state.

  nsITelephonyCallInfo.callState == nsITelephonyService.CALL_STATE_CONNECTED ?

Comment 38

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

Attachment: check-call-state.patch

Hi @jesup, with this patch gUM will be success while call on held, which should be the behavior we had before Oct 27. Could you help confirm this patch works for Loop?

Comment 39

[José Antonio Olivera Ortega [:jaoo]]

(In reply to Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz) from comment #38)
> Created attachment 8548076 [details] [diff] [review]
> check-call-state.patch
> 
> Hi @jesup, with this patch gUM will be success while call on held, which
> should be the behavior we had before Oct 27. Could you help confirm this
> patch works for Loop?

I'll give a try as well. Thanks for the patch!

Comment 40

[José Antonio Olivera Ortega [:jaoo]]

(In reply to José Antonio Olivera Ortega [:jaoo] from comment #39)
> (In reply to Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz) from comment
> #38)
> > Created attachment 8548076 [details] [diff] [review]
> > check-call-state.patch
> > 
> > Hi @jesup, with this patch gUM will be success while call on held, which
> > should be the behavior we had before Oct 27. Could you help confirm this
> > patch works for Loop?
> 
> I'll give a try as well. Thanks for the patch!

Seems to work correctly. See the video at http://youtu.be/d9w-PWkKjOs please.

Comment 41

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

(In reply to José Antonio Olivera Ortega [:jaoo] from comment #40)
> (In reply to José Antonio Olivera Ortega [:jaoo] from comment #39)
> > (In reply to Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz) from comment
> > #38)
> > > Created attachment 8548076 [details] [diff] [review]
> > > check-call-state.patch
> > > 
> > > Hi @jesup, with this patch gUM will be success while call on held, which
> > > should be the behavior we had before Oct 27. Could you help confirm this
> > > patch works for Loop?
> > 
> > I'll give a try as well. Thanks for the patch!
> 
> Seems to work correctly. See the video at http://youtu.be/d9w-PWkKjOs please.

Thanks @jaoo, time to enter the review process.

Comment 42

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

Comment on attachment 8548076 [details] [diff] [review]
check-call-state.patch

Switch to nsITelephonyService because AudioManager.phoneState no longer distinguish between active call and call on held.

Comment 43

[[:fabrice] Fabrice Desré]

Comment on attachment 8548076 [details] [diff] [review]
check-call-state.patch

Review of attachment 8548076 [details] [diff] [review]:
-----------------------------------------------------------------

::: b2g/components/ContentPermissionPrompt.js
@@ +454,5 @@
>  
>  (function() {
>    // Do not allow GetUserMedia while in call.
>    permissionSpecificChecker["audio-capture"] = function(request) {
> +    var forbid = false;

nit: s/var/let

Comment 44

[José Antonio Olivera Ortega [:jaoo]]

(In reply to José Antonio Olivera Ortega [:jaoo] from comment #40)

> Seems to work correctly. See the video at http://youtu.be/d9w-PWkKjOs please.

See the video at https://vimeo.com/116944171.

Comment 45

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

Attachment: check-call-state.patch

update according to review comment, carry r+.

try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=a485a4a9647e

Comment 47

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/b2g-inbound/rev/cb49fd041f7a

Comment 48

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/cb49fd041f7a

Comment 49

[Ryan VanderMeulen [:RyanVM]]

Please nominate this patch for b2g32, b2g34, and b2g37 approval when you get a chance.

Comment 50

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

I consider this as a minor bug. @Maria, how many branches do we want to uplift to?

Comment 51

[Maria Angeles Oteo (:oteo)]

I think it's too late for 2.0, but it would be great it could be uplifted to 2.1 and 2.2 branches.

Shih-Chiang, could you be so kind of asking for the approval in those branches? 
Thanks a lot for asking!

Comment 52

[Ryan VanderMeulen [:RyanVM]]

Note that this bug is currently marked as blocking-b2g:2.0+. Please adjust accordingly if that's not the case.

Comment 53

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

[Blocking Requested - why for this release]:
Changing blocking-b2g flag from 2.0 to 2.1 because of comment #51

Comment 54

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

Comment on attachment 8551013 [details] [diff] [review]
check-call-state.patch

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 1077190
User impact if declined: User cannot pick up Firefox Hello call while GSM call is ongoing.
Testing completed: Manually test on mozilla-central (comment #40)
Risk to taking this patch (and alternatives if risky): minor
String or UUID changes made by this patch: N/A

Comment 55

[bhavana bajaj [:bajaj]]

Comment on attachment 8551013 [details] [diff] [review]
check-call-state.patch

[Triage Comment]

Approving for 2.1/2.2.

Comment 56

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

Approval granted for 2.1/2.2, please help uplifting to b2g34 and b2g37.

Comment 57

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/cdd5f56e7148
https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/07ff1135e88b

Comment 58

[Ryan VanderMeulen [:RyanVM]]

FYI, you don't need to set checkin-needed for uplifts. The B2G Landing wiki has all the bug queries that we use regularly to check for patches that need it.

Comment 59

[Vincent Liu[:vliu]]

https://hg.mozilla.org/releases/mozilla-b2g34_v2_1s/rev/07ff1135e88b