843734 - Dialer UI is glitchy when call is put on hold and STK command for SET_UP_CALL comes

Status: RESOLVED DUPLICATE of bug 832182

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

Description

[Carol Yang [:cyang]]

Attachment: STKUI debug trace

In GCF TC 27.22.4.13.1.4, the test is ran as follows:

- After device boots up and is connected to the network simulator, make a call to '321' from dialer app
- Once call is connected to '321', the GCF test will send a proactive command for SET_UP_CALL to '+012340123456' (displays "On hold" and prompts for user confirmation)
- Upon user confirmation by pressing Ok button, the active call to '321' is put on hold and the call to '+012340123456' is connected
- At the end, the test will prompt for user to terminate the second call ('+012340123456')

At this point, the UI shows an empty SIM Toolkit menu with a green bar on top with no text (showed '321' initially but became no text after user confirmed the new call). Going to the dialer, the UI shows '321' (as if '321 is the active call) on top but with no time duration below. To the right of where time duration should have been is the on hold icon (phone with pause next to it). The only options on the UI is: mute, numpad speaker option and End call button. There is no way to disconnect the second made to '+012340123456'. Even pressing the End call button at this point does nothing visually (the UI remains the same as before pressing the End call button).

Logs with STKUI debug trace turned on are attached.

Comment 1

[Carol Yang [:cyang]]

Note that this is similar to https://bugzilla.mozilla.org/show_bug.cgi?id=835637 but the scenario is to put the existing/active call on hold instead of disconnecting before making the new call.

Comment 2

[Fernando R. Sela (no CC, needinfo please) [:frsela]]

Hi Carol,

With the last Etienne's patch which worked in the bug 835637 (https://bugzilla.mozilla.org/show_bug.cgi?id=835637#c40), fix also this one?

Regarding the "empty STK menu" I'll fix this today.

Regards

Comment 3

[Fernando R. Sela (no CC, needinfo please) [:frsela]]

Attachment: Closing STK section if no menu items were retrieved

Hi Carol,

This is a recursive issue you told me once and again ;)

This patch closes the STK section after an async proactive command if no menu is provided by the SIM Card.

I tested it with success, anyway, I want to ask you if you can test it in order to assure no regressions are introduced with this patch.

Thanks in advance.

Comment 4

[Carol Yang [:cyang]]

(In reply to Fernando R. Sela [:frsela] from comment #2)
> Hi Carol,
> 
> With the last Etienne's patch which worked in the bug 835637
> (https://bugzilla.mozilla.org/show_bug.cgi?id=835637#c40), fix also this one?

Unforunately Etienne's patch from comment 40 does not fix this issue (I've ran it and verified). The scenario is slightly different as this is putting the existing call on hold where as bug 835637 was to disconnect the existing call so seems like the code path is rather different.

> 
> Regarding the "empty STK menu" I'll fix this today.
> 
> Regards

Comment 5

[Fernando R. Sela (no CC, needinfo please) [:frsela]]

Hi Carol,

With the patch I uploaded yesterday the STK empty menu should disapear.

Regarding the green bar on the top of the screen is because the dialer app is not on the foreground (probable because the STK app moved to FG), anyway, the green bar is the correct way of working.

Regards.

Comment 6

[Carol Yang [:cyang]]

(In reply to Fernando R. Sela [:frsela] from comment #5)
> Hi Carol,
> 
> With the patch I uploaded yesterday the STK empty menu should disapear.
> 
> Regarding the green bar on the top of the screen is because the dialer app
> is not on the foreground (probable because the STK app moved to FG), anyway,
> the green bar is the correct way of working.

Hi Fernando,

I was merely describing what the UI looked in detail. I don't think the green bar should not be there. However, the part that still does not seem to be right is when the call is being put on hold, the text of '321' in the green bar goes away. Is that right? It feels like either of the following should be the behavior:

1) The new call to '+012340123456' shows up in the green bar
2) Or perhaps the dialer should be brought to the foreground showing the new call to '+012340123456'

> 
> Regards.

Comment 7

[Fernando R. Sela (no CC, needinfo please) [:frsela]]

(In reply to Carol Yang from comment #6)
> (In reply to Fernando R. Sela [:frsela] from comment #5)
> > Hi Carol,
> > 
> > With the patch I uploaded yesterday the STK empty menu should disapear.
> > 
> > Regarding the green bar on the top of the screen is because the dialer app
> > is not on the foreground (probable because the STK app moved to FG), anyway,
> > the green bar is the correct way of working.
> 
> Hi Fernando,
> 
> I was merely describing what the UI looked in detail. I don't think the
> green bar should not be there. However, the part that still does not seem to
> be right is when the call is being put on hold, the text of '321' in the
> green bar goes away. Is that right? It feels like either of the following
> should be the behavior:
> 
> 1) The new call to '+012340123456' shows up in the green bar
> 2) Or perhaps the dialer should be brought to the foreground showing the new
> call to '+012340123456'
> 
> > 
> > Regards.

Hi Carol,

Which device are you using?

Can you upload a screenshot with the error?

Comment 8

[Carol Yang [:cyang]]

Attachment: Screenshots of TC 27.22.4.13.1.4

Screenshots of the UI while running TC 27.22.4.13.1.4.

Comment 9

[Carol Yang [:cyang]]

(In reply to Fernando R. Sela [:frsela] from comment #7)
> (In reply to Carol Yang from comment #6)
> > (In reply to Fernando R. Sela [:frsela] from comment #5)
> 
> Hi Carol,
> 
> Which device are you using?

Akami

> 
> Can you upload a screenshot with the error?

Please refer to attachment 719192 [details]. Note that Screenshot 2 and 3 is what I see even with your patch to fix the empty STK menu issue. But this isn't the main issue I have. Just wanted to let you know that your patch didn't work :\

My main concern is what you see in Screenshot 4 where '321' is actually on hold and the active call is with '+012340123456' but the UI shows otherwise. Plus there is no way to switch between the calls.

We found a simple way to reproduce this. If you are already on a connecting call, dial another call from the device without using the UI. We are able to reproduce using AT commands to dial the second call. Not sure if you are able to dial a call through some other way but that could help with you debugging this issue.

Comment 10

[Fernando R. Sela (no CC, needinfo please) [:frsela]]

Thanks,

(In reply to Carol Yang from comment #9)
> (In reply to Fernando R. Sela [:frsela] from comment #7)
> > (In reply to Carol Yang from comment #6)
> > > (In reply to Fernando R. Sela [:frsela] from comment #5)
> > 
> > Hi Carol,
> > 
> > Which device are you using?
> 
> Akami
> 
> > 
> > Can you upload a screenshot with the error?
> 
> Please refer to attachment 719192 [details]. Note that Screenshot 2 and 3 is
> what I see even with your patch to fix the empty STK menu issue. But this
> isn't the main issue I have. Just wanted to let you know that your patch
> didn't work :\
> 

Well, closing the empty menu is another issue, I'll check this again.

> My main concern is what you see in Screenshot 4 where '321' is actually on
> hold and the active call is with '+012340123456' but the UI shows otherwise.
> Plus there is no way to switch between the calls.
> 
> We found a simple way to reproduce this. If you are already on a connecting
> call, dial another call from the device without using the UI. We are able to
> reproduce using AT commands to dial the second call. Not sure if you are
> able to dial a call through some other way but that could help with you
> debugging this issue.

This other one I think is a dialer issue and not STK. Borja, WDYT?

Comment 11

[Andrew Overholt [:overholt]]

How are things progressing here?

Comment 12

[Andrew Overholt [:overholt]]

Anyone have information as to how this bug is progressing?

Comment 13

[Carol Yang [:cyang]]

There was a fix done a while back with https://bugzilla.mozilla.org/show_bug.cgi?id=834977. Not sure if the fix would be similar but maybe something to consider looking at to help with the current issue?

Comment 14

[Fernando R. Sela (no CC, needinfo please) [:frsela]]

The main bug, if I understood well, is that the second number is not displayed into the green bar.

If I'm correct, this is a bug in dialer or attention screen.

Comment 15

[Daniel Coloma:dcoloma]

Changing the needinfo to etienne as I believe he is a better one to provide feedback about this

Comment 16

[Carol Yang [:cyang]]

(In reply to Fernando R. Sela [:frsela] from comment #14)
> The main bug, if I understood well, is that the second number is not
> displayed into the green bar.

This is one of the bugs but not the only one. Both Screenshots 3 and 4 from attachment 719192 [details] are UI bugs that I'm seeing. Screenshot 3 is what you have mentioned (the second number not displayed in the green bar). Screenshot 4 is displaying the wrong active call (it shows 321 even though 321 is put on hold and the active call is +012340123456).

> 
> If I'm correct, this is a bug in dialer or attention screen.

Comment 17

[Etienne Segonzac (:etienne)]

(In reply to Daniel Coloma:dcoloma from comment #15)
> Changing the needinfo to etienne as I believe he is a better one to provide
> feedback about this

More than feedback, great news!
I'm pretty confident that the r+ed patch on bug 832182 will fix the dialer issue here.

Comment 18

[Carol Yang [:cyang]]

(In reply to Etienne Segonzac (:etienne) from comment #17)
> (In reply to Daniel Coloma:dcoloma from comment #15)
> > Changing the needinfo to etienne as I believe he is a better one to provide
> > feedback about this
> 
> More than feedback, great news!
> I'm pretty confident that the r+ed patch on bug 832182 will fix the dialer
> issue here.

Hi Etienne, I don't seem to have access to bug 832182. Is there any chance the patch can be shared with us so I can pull the change in manually just to test it out?

Comment 19

[Etienne Segonzac (:etienne)]

(In reply to Carol Yang from comment #18)
> (In reply to Etienne Segonzac (:etienne) from comment #17)
> > (In reply to Daniel Coloma:dcoloma from comment #15)
> > > Changing the needinfo to etienne as I believe he is a better one to provide
> > > feedback about this
> > 
> > More than feedback, great news!
> > I'm pretty confident that the r+ed patch on bug 832182 will fix the dialer
> > issue here.
> 
> Hi Etienne, I don't seem to have access to bug 832182. Is there any chance
> the patch can be shared with us so I can pull the change in manually just to
> test it out?

The patch is here: https://github.com/mozilla-b2g/gaia/pull/8610

Comment 20

[Daniel Coloma:dcoloma]

(In reply to Etienne Segonzac (:etienne) from comment #19)
> (In reply to Carol Yang from comment #18)
> > (In reply to Etienne Segonzac (:etienne) from comment #17)
> > > (In reply to Daniel Coloma:dcoloma from comment #15)
> > > > Changing the needinfo to etienne as I believe he is a better one to provide
> > > > feedback about this
> > > 
> > > More than feedback, great news!
> > > I'm pretty confident that the r+ed patch on bug 832182 will fix the dialer
> > > issue here.
> > 
> > Hi Etienne, I don't seem to have access to bug 832182. Is there any chance
> > the patch can be shared with us so I can pull the change in manually just to
> > test it out?
> 
> The patch is here: https://github.com/mozilla-b2g/gaia/pull/8610

Is bug 832182 also tef+? I do not have access either

Comment 21

[Carol Yang [:cyang]]

(In reply to Etienne Segonzac (:etienne) from comment #19)
> (In reply to Carol Yang from comment #18)
> > (In reply to Etienne Segonzac (:etienne) from comment #17)
> 
> The patch is here: https://github.com/mozilla-b2g/gaia/pull/8610

Hi Etienne, thanks for sharing the patch! We tried it out here and it does seem to have fixed the issue reported!

Just curious though, I had manually pulled this into a v1.0.1 branch. The changes in telephony_helper.js cannot be applied to v1.0.1 as displayMessage func does not exist here. As Daniel has already asked in Comment 20, will 832182 also be tef+ to make sure the merge will be ok for v1.0.1 branch?

Comment 22

[Etienne Segonzac (:etienne)]

> Just curious though, I had manually pulled this into a v1.0.1 branch. The
> changes in telephony_helper.js cannot be applied to v1.0.1 as displayMessage
> func does not exist here. As Daniel has already asked in Comment 20, will
> 832182 also be tef+ to make sure the merge will be ok for v1.0.1 branch?

I asked for bug 832182 to be made public and tef+.

Comment 23

[Daniel Coloma:dcoloma]

Unassigning from frsela

Comment 24

[Andrew Overholt [:overholt]]

Bug 832182 is now tef+.  I'm working on opening it up.

Comment 25

[Wayne Chang [:wchang]]

Carol/Etienne, Can either of you confirm this bug is a dup of bug 832182 and we can resolve this one as duplicated?