1052621 - [B2G][Loop] When user disable the Mic, the notification will still display the Mic is enable

Status: RESOLVED WONTFIX

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

Description

[pete siphantong [:Petes]]

Attachment: logcat_20140812_1115.txt

Description:
When user disable the Mic, pulling down the notification bar will still display the Mic is enable 

Setup: 
- Install the Loop app on two devices from: https://github.com/mozilla-b2g/firefoxos-loop-client
- Sign into Loop app using Firefox Accounts

Repro Steps:
1) Update a Flame to 20140812000205
2) On both Devices: Confirm devices have contacts added containing Firefox Account email
3) Select Loop App> Select Contact Icon(base of screen)
4) Make a call from the contact
5) While on the call, tap the '...'
6) Tap the Mic icon > pull down the notification bar 

Actual:
Mic display enable when it is disable 

Expected:
Mic is disable 

Environmental Variables:
Device: Flame 2.0
Build ID: 20140812000205
Gaia: 1144cdc3a544f81c9bf71598aba1cb67d6c95a29
Gecko: 6495a7bd61ed
Version: 32.0 (2.0)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0


Note: the mic is on before disabling, mic is still on afterwards 


Repro frequency: 3/3
See attached: screenshot and logcat attached

Comment 1

[pete siphantong [:Petes]]

Attachment: 2014-08-12-11-15-54.png

Comment 2

[pete siphantong [:Petes]]

Attachment: 2014-08-12-11-16-06.png

Comment 3

[pete siphantong [:Petes]]

This issue also reproduce on Flame 2.1 (319mb), Buri 2.1, Flame 2.0 (512mb), Buri 2.0. Mic display enable when it is disable.

Flame 2.1 (319mb)

Environmental Variables:
Device: Flame Master
Build ID: 20140812040201
Gaia: e78e62125eb43c3a28cdc047987ba54430694a2f
Gecko: b53c2753ce9a
Version: 34.0a1 (Master)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Buri 2.1

Environmental Variables:
Device: Buri Master
Build ID: 20140812073020
Gaia: e78e62125eb43c3a28cdc047987ba54430694a2f
Gecko: ee1ad12a3939
Version: 34.0a1 (Master)
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0


Flame 2.0 (512mb)

Environmental Variables:
Device: Flame 2.0
Build ID: 20140812000205
Gaia: 1144cdc3a544f81c9bf71598aba1cb67d6c95a29
Gecko: 6495a7bd61ed
Version: 32.0 (2.0)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Buri 2.0

Environmental Variables:
Device: Buri 2.0
Build ID: 20140812063006
Gaia: 88e774c606520c9ce349b467866e200e8db31af4
Gecko: d37b1bd92b3d
Version: 32.0 (2.0)
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
 
_________________________________________________________________________________________________________________________

This issue does not reproduce on the Flame 1.4 (319mb), Buri 1.4, and the Buri 1.3 because the feature was not implemented.

Flame 1.4 (319mb)

Environmental Variables:
Device: Flame 1.4
Build ID: 20140812063005
Gaia: ec395d47cee9234ae93d2410d8ef8724dfc5d6cb
Gecko: 5b219153e2f4
Version: 30.0 (1.4)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Buri 1.4

Environmental Variables:
Device: Buri 1.4
BuildID: 20140812063005
Gaia: ec395d47cee9234ae93d2410d8ef8724dfc5d6cb
Gecko: 5b219153e2f4
Version: 30.0 (1.4)
Firmware: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Buri 1.3

Environmental Variables:
Device: Buri 1.3
BuildID: 20140811024001
Gaia: 23f55be856cef53c6604a6fe4aeb09061afbc897
Gecko: ac685e277c7c
Version: 28.0 (1.3)
Firmware: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:28.0) Gecko/28.0 Firefox/28.0

Comment 4

[pete siphantong [:Petes]]

This issue was found on the Flame 2.0 (319)

Comment 5

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

mbarone this seems like it could be a possible blocker. Could you weigh in on this issue please?

Comment 6

[Maria Angeles Oteo (:oteo)]

(In reply to KTucker [:KTucker] from comment #5)
> mbarone this seems like it could be a possible blocker. Could you weigh in
> on this issue please?

The issue here is that when muting the call, the Loop App is still accessing the microphone, as the TB SDK is still accessing it, because of that, the recording indication is still shown. We don't think it's a blocker and furthermore, there is little we can't do in order to solve this.

Comment 7

[Maria Angeles Oteo (:oteo)]

Setting ni to me, to remind me to check the status of this issue

Comment 8

[Borja Salguero [:borjasalguero]]

Hi all,
Dut to TB SDK we are requesting both Streams (audio and video), and internally we are stopping video/audio by request through Loop UI. This means that we are always asking permissions for both (regardless we use them or not), because we can enable during the call.
This is due to currently we can not change the constraints 'on the fly' during a WebRTC call. I hope it helps!

Comment 9

[Borja Salguero [:borjasalguero]]

Pete, in this case it seems that there is no solution for this due to WebRTC does not support changing the constraints on the fly, and with TB we are requesting all streams for doing a workaround to that missing functionality (so nothing we can do at Loop level)
Should we close this bug? Thanks!

Comment 10

[pete siphantong [:Petes]]

Borja, yeah if that is the case then I think that this bug should be closed

Comment 11

[Maria Angeles Oteo (:oteo)]

Fixing this could imply a significant amount of work, involving Tokbox, Loop app and perhaps Platform, so we can not fix it for first Loop version.