Closed
Bug 1057579
Opened 11 years ago
Closed 11 years ago
[Loop]Video calls are still made with Audio set as the default call mode
Categories
(Firefox OS Graveyard :: Gaia::Loop, defect, P1)
Tracking
(b2g-v2.0 affected, b2g-v2.1 affected)
VERIFIED
FIXED
People
(Reporter: JMercado, Assigned: borjasalguero)
References
()
Details
(Whiteboard: [mobile app][blocking][2.0-exploratory-kk][patch available])
Attachments
(2 files)
Description:
When the user selects Audio as their default call mode, the phone will still send a video feed by default.
Repro Steps:
1) Update a Flame to 20140822030000
2) Create a contact with an email address
3) Install Loop on the device and sign in
4) Change the default call mode to Audio
5) Call the contact created in step 2
Actual:
The call is started as a video call.
Expected:
The call is started as an audio call.
Environmental Variables:
Device: Flame 2.0 (319 MB)
Build ID: 20140822030000
Gaia: 06edd086387c2150017b549e6318a61cd7e4fd02
Gecko: 6329352ca531b977979451e77e5862af485388b2
Version: 32.0 (2.0)
Firmware Version: v165
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Loop Version: 2a10cd6
Repro frequency: 100%
See attached: video, logcat
Reporter | ||
Comment 1•11 years ago
|
||
This issue does occur on Flame 2.1, Flame 2.0 on v123, Flame 2.0 on v165 KK (512 MB), and OpenC 2.0
The call will always default to Video mode.
Environmental Variables:
Device: Flame Master
BuildID: 20140822040202
Gaia: afcdd36f13e75adcdebe57d842a277fd587faf28
Gecko: 0b9dd32d1e16
Version: 34.0a1 (Master)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Environmental Variables:
Device: Flame 2.0
BuildID: 20140822000206
Gaia: 64b0c0ae60fdeac953a7e2a3c368d124bf848477
Gecko: 5075528d7241
Version: 32.0 (2.0)
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Environmental Variables:
Device: Flame 2.0 (512 MB)
BuildID: 20140822030000
Gaia: 06edd086387c2150017b549e6318a61cd7e4fd02
Gecko: 6329352ca531b977979451e77e5862af485388b2
Version: 32.0 (2.0)
Firmware Version: v165
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Environmental Variables:
Device: Open_C 2.0
BuildID: 20140822000206
Gaia: 64b0c0ae60fdeac953a7e2a3c368d124bf848477
Gecko: 5075528d7241
Version: 32.0 (2.0)
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Loop Version: 2a10cd6
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Comment 3•11 years ago
|
||
Massimo, can you weigh in on this issue please? Seems like a potential blocker.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker) → needinfo?(mbarone976)
Updated•11 years ago
|
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
Comment 4•11 years ago
|
||
Jaime, can you clarify step 5 in the STR?
How have you called that contact?
There are three options to start a Direct Loop Mobile Call:
1)Tapping on a Call Log entry in the Call Log of the Loop Mobile Application (in this case the new should be of the same type of the call log entry - i.e. the default call mode is not taken into account)
2)Picking a contact in the Contact List inside Loop Mobile Application (in this case the default call mode in Loop settings is used)
3)Entering in the Contact application and tapping on the specific Loop buttons (audio or video buttons) in the contact details screen (the default mode is not taken into account)
Flags: needinfo?(jmercado)
Updated•11 years ago
|
Whiteboard: [2.0-exploratory-kk] → [2.0-exploratory-kk] [feedback pending]
Reporter | ||
Comment 5•11 years ago
|
||
Maria
The steps were written up with case 1 in mind, but the same occurs if step 2 with an audio conversation. The result is that a video call is always started.
Flags: needinfo?(jmercado)
Comment 6•11 years ago
|
||
(In reply to Jayme Mercado [:JMercado] from comment #5)
> Maria
> The steps were written up with case 1 in mind, but the same occurs if step 2
> with an audio conversation. The result is that a video call is always
> started.
Thanks! For the sake of clarity:
- In case 1, the default call mode must be ignored.
A/ If you click on a video call log entry, a video call must be always started.
B/ If you click on an audio call log entry, an audio call must be always started.
- In case 2, the default call mode must be always used:
C/ If the default call mode is video, a video call must be always started.
D/ If the default call mode is audio, an audio call must be always started.
Which of these 4 scenarios (A,B,C,D) are currently not working as expected? Thanks!
Flags: needinfo?(jmercado)
Reporter | ||
Comment 7•11 years ago
|
||
Maria
Scenarios B and D above do not work as expected. A video call will start instead of an audio call.
Flags: needinfo?(jmercado)
Comment 8•11 years ago
|
||
Thanks a lot Jayme!
Totally right, I am reproducing them right now, it seems something has been broken because this was working before my holidays.
Blocking bug, Borja, can you have a look at it? Thanks!
Flags: needinfo?(borja.bugzilla)
Whiteboard: [2.0-exploratory-kk] [feedback pending] → [mobile app][blocking]
Updated•11 years ago
|
Whiteboard: [mobile app][blocking] → [mobile app][blocking][2.0-exploratory-kk]
Assignee | ||
Comment 9•11 years ago
|
||
Taking this! I'll try to upload a patch tomorrow :)
Assignee: nobody → borja.bugzilla
Flags: needinfo?(borja.bugzilla)
Updated•11 years ago
|
Priority: -- → P1
Assignee | ||
Comment 10•11 years ago
|
||
From product perspective, the requirement is that we need to make the call taking into account the status of the previous call, so if an entry was a video-call, tapping on it will be a video-call regardless the 'default-call-mode' setting in Settings. I'll upload a patch following this.
Assignee | ||
Comment 11•11 years ago
|
||
With this patch, when tapping on a calllog entry, we will launch the call following the same params related to video/audio.
Attachment #8487056 -
Flags: review?(josea.olivera)
Updated•11 years ago
|
Whiteboard: [mobile app][blocking][2.0-exploratory-kk] → [mobile app][blocking][2.0-exploratory-kk][patch available]
Comment 12•11 years ago
|
||
Comment on attachment 8487056 [details] [review]
Pull Request
LGTM. r=me
Thanks for taking care of it Borja!
Attachment #8487056 -
Flags: review?(josea.olivera) → review+
Assignee | ||
Updated•11 years ago
|
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Comment 13•11 years ago
|
||
Verified on:
Flame: user.v2.0.184based.B-57.Gecko-dde9d61.Gaia-7b8df99
FireE: firee-kk-v2.0-SW2E5-4
Loop 1.1, version: aba155c
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•