1019090 - Call on hold visual refresh

Status: RESOLVED INVALID

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

Description

[Anthony Ricaud (:rik)]

Attachment: call-hold.png

Call on hold does not match the spec.

Comment 1

[Anthony Ricaud (:rik)]

attachment 8432639 [details] should look like attachment 8415234 [details]

Comment 2

[Stephany Wilkes]

Who is implementing this change in advance of the end of Sprint 3 on Friday? This is blocking the 2.0 Visual Refresh.

Comment 3

[Germán Toro del Valle (:gtorodelvalle)]

Attachment: callscreen_singlecall_number_held.png

Hi Anthony, could you please tell me how to get that screen? I do not have a Bluetooth device and I cannot set the ongoing call on hold. Anyhow, setting the call status to "connected-hold" I am getting the attached screen using master code. Thanks! (sorry, I cannot connect to the IRC from Taipei :( )

Comment 4

[Germán Toro del Valle (:gtorodelvalle)]

Need-infoing Anthony regarding comment 3 ;-)

Comment 5

[Anthony Ricaud (:rik)]

I use the app manager to log into the communications app (or any app with the telephony permission). And then in the console: |navigator.mozTelephony.active.hold()|

Comment 6

[Germán Toro del Valle (:gtorodelvalle)]

Hi Anthony, are you sure that's a valid use case. I mean I checked the code and when there is only 1 ongoing call and it is put on hold https://github.com/mozilla-b2g/gaia/blob/master/apps/callscreen/js/calls_handler.js#L549 , the call screen status is set to "connected-hold" which makes attachment 8434784 [details] to be shown (the other invocations of |navigator.mozTelephony.active.hold()| do not apply when there are more than 1 call).

Comment 7

[Germán Toro del Valle (:gtorodelvalle)]

BTW, consequently to my previous comment, rules of the type |#calls.big-duration > section.held| would not apply (which we currently have in https://github.com/mozilla-b2g/gaia/blob/master/apps/callscreen/style/oncall.css ) and if you agree we could use this bug to do some clean up there :-)

Comment 8

[Anthony Ricaud (:rik)]

Oh right, we're good here. Removing dependencies.

I've opened this bug because Vivien was using this simple command during loop development. Maybe we should change the code to just do the call to .hold() and have the event handler for callschanged determine the call screen state.

Vivien: are you going to hold "real" phone calls from Loop with just |navigator.mozTelephony.active.hold()| ?

Comment 9

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Anthony Ricaud (:rik) from comment #8)
> Oh right, we're good here. Removing dependencies.
> 
> I've opened this bug because Vivien was using this simple command during
> loop development. Maybe we should change the code to just do the call to
> .hold() and have the event handler for callschanged determine the call
> screen state.
> 
> Vivien: are you going to hold "real" phone calls from Loop with just
> |navigator.mozTelephony.active.hold()| ?

I'm not :)

Comment 10

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

According to comment 8 and comment 9, let's remove feature-b2g for now.
Set 2.0? to triage in case we still need it for Loop development.

Comment 11

[Stephany Wilkes]

Vicky, can this slip from 2.0? Flagging to check.

Comment 12

[Anthony Ricaud (:rik)]

Stephany: The screenshot in attachment 8432639 [details] is actually never displayed in real usage. Germán in attachment 8434784 [details] showed what the screen currently looks like which is per spec. We're not slipping anything for 2.0, it was just a false alert.

Comment 13

[Stephany Wilkes]

Then we shouldn't just move but resolve invalid, no?

Comment 14

[Anthony Ricaud (:rik)]

Wesley wants to coordinate with Loop development (see comment 10) this is why it is still open. If it isn't needed, we'll close.

Comment 15

[Maria Angeles Oteo (:oteo)]

According to the latest version of the Attention Screen patch (bug 988212) Loop is not using the activeCall.hold() so we can close this bug as invalid. Setting NI to Borja to confirm it.

Comment 16

[Tony Chung [:tchung]]

This sounds like a feature-b2g=2.0? bug, not a blocking-b2g bug.  if this is a feature request, please nominate it using the flag.

also, per comment 15, it does not sound like this is need by the Loop client.  however, triage needs to know if this visual refresh work affects the rest of the caller work.  product, please comment if this is a needed feature for 2.0, and UX, please chime in with design. 

renom when done.  thanks

Comment 17

[Stephany Wilkes]

Flagging Victoria and Carrie to make a blocking call here.

Comment 18

[Victoria Gerchinhoren [:vicky]]

Hi Stephany, 
What do you need my input here for? Is not clear for me. 

(In reply to Stephany Wilkes from comment #17)
> Flagging Victoria and Carrie to make a blocking call here.

Comment 19

[Stephany Wilkes]

Victoria see comment #16.

Comment 20

[Borja Salguero [:borjasalguero]]

Regarding this we need to wait until solving the issue with the 'telephony' channel, and the 'hold' policy to apply. This is being discussed in https://bugzilla.mozilla.org/show_bug.cgi?id=1016277, and we need to wait for applying the final solution.

If no change is needed, I'll close this as invalid.

Comment 21

[Carrie Wang [New account: [e-mail]]]

I've checked this with Vicky. From the design perspective, attachment 8434784 [details] looks good to us. We don't think it's a blocker.

Comment 22

[Wilfred Mathanaraj [:WDM]]

so this is a non-issue? can we close this if this is a non-issue?

Comment 23

[Maria Angeles Oteo (:oteo)]

yes, it's not an issue, closing as invalid