[Dialer] Callscreen overlaps conference call screen

RESOLVED WONTFIX

Status

Firefox OS
Gaia::Dialer
RESOLVED WONTFIX
4 years ago
5 months ago

People

(Reporter: SalvadorR, Assigned: gtorodelvalle)

Tracking

unspecified
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

(b2g-v1.4 affected, b2g-v2.0 affected, b2g-v2.1 affected, b2g-v2.2 affected)

Details

(Whiteboard: [2.1-exploratory-3][planned-sprint c=1][in-sprint=v2.1-S9])

Attachments

(4 attachments)

(Reporter)

Description

4 years ago
Created attachment 8515172 [details]
callscreen overlap.png

Description:
When user is in a Conference Call and is in the screen that displays all of the contacts in the conference call, if user receives a call, the call screen will overlap the conference call screen
   
Repro Steps:
1) Update a Flame device to BuildID: 20141031001201
2) Start a conference call with multiple contacts
3) Select the Conference Call in the Dialer app and you'll be brought to a screen that displays all the contacts in the call
4) Receive a call while staying in the conference call screen
5) Observe Call Screen
  
Actual:
Call Screen overlaps conference call screen
  
Expected: 
Call Screen appears properly
  
Environmental Variables:
Device: Flame 2.1 (319mb) KK Full Flash
BuildID: 20141031001201
Gaia: f89c7b12c36572262c9ea76058694a139b1a8634
Gecko: 50d48f8a04c7
Gonk: 6e51d9216901d39d192d9e6dd86a5e15b0641a89
Version: 34.0 (2.1)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
  
Repro frequency: 3/3
See attached: Screenshot, Logcat
Flags: needinfo?(jmitchell)
(Reporter)

Comment 1

4 years ago
Created attachment 8515173 [details]
logcat_20141031_1145.txt
(Reporter)

Comment 2

4 years ago
This issue also occurs on Flame 2.0 and Flame 2.2

Results: Callscreen overlaps conference call screen

Flame 2.0

Device: Flame 2.0 (319mb)(Kitkat Base)(Full Flash)
BuildID: 20141031000201
Gaia: 7b8df9941700c1f6d6d51ff464f0c8ae32008cd2
Gecko: 82a6ed695964
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 32.0 (2.0) 
Firmware Version: v188
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Flame 2.2

Device: Flame 2.2 Master (319mb)(Kitkat Base)(Full Flash)
BuildID: 20141031061804
Gaia: a07994714f0552f89801d6097982308d8b0a1ee1
Gecko: 6bd2071b373f
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 36.0a1 (2.2) 
Firmware Version: v188
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0
QA Whiteboard: [QAnalyst-Triage?]
NI Dialer owner to make a blocking decision - buttons are still usable - bug is bad visual / ux
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell) → needinfo?(jlorenzo)
I checked on a Buri and the issue was there in 1.4:
Gaia-Rev        b06fee13c1d80bd2a463be1f2fb1d59169af9298
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/540ef440c9a9
Build-ID        20141013000203
Version         30.0
Device-Name     msm7627a
FW-Release      4.0.4
FW-Incremental  eng.tclxa.20131223.163538
FW-Date         Mon Dec 23 16:36:04 CST 2013

I wouldn't block a release on that, but I think this is a good nice to have. What do you think Doug? Should we attach this issue on the meta-bug dialer-most-wanted?
status-b2g-v1.4: --- → affected
Flags: needinfo?(jlorenzo) → needinfo?(drs.bugzilla)
(In reply to Johan Lorenzo [:jlorenzo] (QA) from comment #4)
> I wouldn't block a release on that, but I think this is a good nice to have.
> What do you think Doug? Should we attach this issue on the meta-bug
> dialer-most-wanted?

Since it's not a regression, we generally won't make it block the next release. But I think that this is bad enough that we should definitely get right on it.

Germán, do you have the bandwidth to take this?
Blocks: 1036516
Flags: needinfo?(drs.bugzilla) → needinfo?(gtorodelvalle)
Sure! Taking it... ;)
Assignee: nobody → gtorodelvalle
Flags: needinfo?(gtorodelvalle)
Hi guys! Issue confirmed ;) Definitely a case we did not take into consideration :( Consequently, we need some UX magic here so need-infoing Carrie about the issue. As a suggestion since it should straight-forward to do it, a possibility would be to close the participant list overlay when a new incoming call reaches the phone. What do you think, Carrie? :)
Flags: needinfo?(cawang)
Whiteboard: [2.1-exploratory-3] → [2.1-exploratory-3][planned-sprint c=]
Target Milestone: --- → 2.1 S9 (21Nov)
Hi Germán:

I'd imagine that the call screen will overplay the participants list page, and after taking actions on the incoming call screen, they will get back to the updated call screen (no matter it's declined or accepted). So the participants list is closed while users are dealing with the new incoming call screen. 


What do you say? Thanks!
Flags: needinfo?(cawang)
Whiteboard: [2.1-exploratory-3][planned-sprint c=] → [2.1-exploratory-3][planned-sprint c=1]
Created attachment 8519982 [details]
[screenshot] additional incoming call

Hi Carrie,

I'm sorry but just to be sure :) My suggestion was to close the participant list before showing the new incoming call to let the user take action on it. Consequently, once the conference call participant list is closed, the user will be in the main call screen page from which the user will be able to take action on the new incoming call. Once the user decides what to do with this new incoming call, the user will be kept on the main call screen page. Was this what you were also suggesting? :) After re-reading your comment I think we are talking of the same thing here ;)

BTW, the reason to close the participant list is because the second incoming call area goes up from the bottom of the screen (please see the new attachment) and I guess you do not want this second incoming call area to go up from the bottom over the participant list.

Anyhow and since it is straight-forward to do it, I'll implement the suggested solution and upload a video so you can check it.

Thanks!
Flags: needinfo?(cawang)
Hi Germán,

That's very close to what I meant in comment 8. I got wrong impression that we can overlay the call screen on the participants list, but now I understand that we shall close it before we bring up the half-paged second incoming call screen. Anyways, I think what you described in comment 9 is good to go! Thanks!
Flags: needinfo?(cawang)
Uhm! There's a situation we did not take into account :(

Imagine a conference call is established, the participant list displayed and a new incoming call reaches the phone. As suggested, the participant list overlay is automatically hidden before the incoming call area is shown from the bottom. But, what happens if while the second incoming call area is shown, the user clicks on the "display conference call participant list" arrow (>) in the conference call header :O We would end up in a scenario pretty similar to what is depicted in attachment 8515172 [details] :(

And it is probably trickier than it may seem at first glance because if we decide that the overlay should go over any other information shown by the call screen (even second incoming calls), the user may not notice that a new incoming call is reaching the phone. On the other hand, if we decide that the second incoming call area is shown over the overlay, there would be no way to interact with (the lower part of) the overlay (to close it or to hang any of the calls taking part on the conference up) because the second incoming call would be on top of this actionable area :O

Of course, the other option would be not to let the user expand the participant list overlay while a second incoming call is reaching the phone. But what if this is what the user wants to do before attending the new call, for example to hang some of the calls taking part in the conference call up :O

I know some of these are kind of corner cases but "users are weird" :p

We need some of you magic here, Carrie! :p Thanks!
Flags: needinfo?(cawang)
Hi Germán, 

I think if user is already at the call screen while the second incoming call is connecting and he decide to access the participants list at the same time, we can deal it as the scenario that users tap Home button while a call is connecting. So the new screen will cover the call screen and users need to drag down the notification to open the call screen again, but there will be a flashing blue line and a temporary dropped-down notification at the screen top to indicate them. 

So we can adopt this pattern to multiple calls scenario. If second incoming call is connecting and users tap the participants list, the list will pop up and replace the call screen. Meanwhile, the flashing blue line appears with a dropped-down notification which shows "<contact name>  Incoming". Users can drag down the notification tray and tap it to go back to the call screen or they can close the participants list to go back there too. 

How does this sound to you? :)
Thanks!
Flags: needinfo?(cawang)
Whiteboard: [2.1-exploratory-3][planned-sprint c=1] → [2.1-exploratory-3][planned-sprint c=1][in-sprint=v2.1-S9]
Target Milestone: 2.1 S9 (21Nov) → 2.2 S1 (5dec)
(In reply to Carrie Wang [:carrie] from comment #12)
> I think if user is already at the call screen while the second incoming call
> is connecting and he decide to access the participants list at the same
> time, we can deal it as the scenario that users tap Home button while a call
> is connecting. So the new screen will cover the call screen and users need
> to drag down the notification to open the call screen again, but there will
> be a flashing blue line and a temporary dropped-down notification at the
> screen top to indicate them. 
> 
> So we can adopt this pattern to multiple calls scenario. If second incoming
> call is connecting and users tap the participants list, the list will pop up
> and replace the call screen. Meanwhile, the flashing blue line appears with
> a dropped-down notification which shows "<contact name>  Incoming". Users
> can drag down the notification tray and tap it to go back to the call screen
> or they can close the participants list to go back there too. 

Carrie, thanks for the suggestion. I generally like it, but I think that this may be slightly overengineering the solution. It is not trivial right now to show both: the Callscreen maximized, the call notification toast. If we close the conference call participants list, the user has to make a concerted effort to open it again. I think it's safe to assume that the user will see that a new call is incoming, and this is why the participant list was closed.

My suggestion is to do the following when receiving a call while the conference call participants list is open:
1. Close the conference call participants list, as you suggested.
2. Make sure that, if the user re-opens it while an incoming call is coming, we display it correctly. i.e., none of the bad layering as illustrated in attachment 8515172 [details]. Also as you suggested.
3. (optional) Open a followup bug to consider showing the call notification toast in this scenario. I personally don't think that doing this is worth the effort, but I'm happy to discuss this further.

How does that sound to you?
Flags: needinfo?(cawang)
Hi Doug, 


I agree with you that actually we don't need to over think the issue here. Let's just close the list correctly when there has a second incoming call coming up and open the participants list directly while user is not taking action on the incoming call but accessing the conference call list. I think if we can open the expected page correctly, it's no need to work on the suggestion I propose in comment 12. Thanks!
Flags: needinfo?(cawang)
Created attachment 8529705 [details] [review]
Pull request 26524

Patch implementing what we have commented available ;)

As a side note and to help you with the review, Doug, I have to properly cover a concrete scenario consisting in the following:
 1. Establish a conference call.
 2. Make a second incoming call to the DuT.
 3. Expand the conference call participant list.
 4. Hang up any of the calls participating in the conference call.

With the already existent code, the incoming call panel was closed. Now, it is kept shown and the call screen properly updated, showing the still ongoing conference call or the pending 1 to 1 call in case the one leaving the conference call was the last one.

That's the reason of the new |secondIncomingCall| variable in CallsHandler ;)
Attachment #8529705 - Flags: review?(drs.bugzilla)
Comment on attachment 8529705 [details] [review]
Pull request 26524

(In reply to Germán Toro del Valle from comment #15)
> With the already existent code, the incoming call panel was closed. Now, it
> is kept shown and the call screen properly updated, showing the still
> ongoing conference call or the pending 1 to 1 call in case the one leaving
> the conference call was the last one.
> 
> That's the reason of the new |secondIncomingCall| variable in CallsHandler ;)

I don't follow. This doesn't seem like what we agreed on. However, I'm having trouble testing this as my carrier doesn't allow me to receive an incoming call when a conference call is already ongoing.
Flags: needinfo?(gtorodelvalle)
Attachment #8529705 - Flags: review?(drs.bugzilla)
(In reply to Doug Sherk (:drs) (use needinfo?) from comment #16)
> Comment on attachment 8529705 [details] [review]
> Pull request 26524
> 
> (In reply to Germán Toro del Valle from comment #15)
> > With the already existent code, the incoming call panel was closed. Now, it
> > is kept shown and the call screen properly updated, showing the still
> > ongoing conference call or the pending 1 to 1 call in case the one leaving
> > the conference call was the last one.
> > 
> > That's the reason of the new |secondIncomingCall| variable in CallsHandler ;)
> 
> I don't follow. This doesn't seem like what we agreed on. However, I'm
> having trouble testing this as my carrier doesn't allow me to receive an
> incoming call when a conference call is already ongoing.

Yeah, sorry, this comment was referring to a concrete scenario which was not covered properly with the already existent code (before my patch). The scenario is the following one:
  1. Establish a call.
  2. Establish a second (incoming or outgoing) call to the DuT.
  3. Merge both calls.
  4. Make a third call to the DuT.
  5. Hang up any of the calls taking part in the conference.

OBERVED:
  6. The call screen shows a 1 to 1 call to the call participating in the conference call which did not leave the conference. The incoming call panel of the third call is wrongly closed since it is still trying to be established.

EXPECTED:
  6. The call screen shows a 1 to 1 call to the call participating in the conference call which did not leave the conference as well as the incoming call panel of the third call since it is still trying to be established.

To solve it I needed to include this new |secondIncomingCall| to filter the cases when the incoming panel should and should not be closed.

Apart from this particular scenario, the main scenario covered and solved by the proposed patch is the following one:
  - If the conference call participant list is shown and an additional incoming call reaches the phone, the conference call participant list is closed.
  - If when a conference call is ongoing, an additional incoming call reaches the phone and the user expands the conference call participant list, the participant list overlay is shown over the call screen.

I hope I made myself clearer now :)

BTW, I'll record a video ASAP but sadly from Portland I am not able to. I'll check with you if there are SIM cards available to do it ;)
Flags: needinfo?(gtorodelvalle) → needinfo?(drs.bugzilla)
Target Milestone: 2.2 S1 (5dec) → ---
Flags: needinfo?(drs)

Comment 18

5 months ago
Firefox OS is not being worked on
Status: NEW → RESOLVED
Last Resolved: 5 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.