Who is implementing this change in advance of the end of Sprint 3 on Friday? This is blocking the 2.0 Visual Refresh.
Assignee: nobody → gtorodelvalle
feature-b2g: --- → 2.0
Target Milestone: --- → 2.0 S3 (6june)
Created attachment 8434784 [details] 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 :( )
Need-infoing Anthony regarding comment 3 ;-)
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()|
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).
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 :-)
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()| ?
No longer blocks: 950760
Flags: needinfo?(anthony) → needinfo?(21)
Target Milestone: 2.0 S3 (6june) → ---
(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 :)
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.
blocking-b2g: --- → 2.0?
feature-b2g: 2.0 → ---
Vicky, can this slip from 2.0? Flagging to check.
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.
Then we shouldn't just move but resolve invalid, no?
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.
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.
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
blocking-b2g: 2.0? → ---
Flagging Victoria and Carrie to make a blocking call here.
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.
Victoria see comment #16.
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.
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.
so this is a non-issue? can we close this if this is a non-issue?
Flags: needinfo?(wmathanaraj) → needinfo?(borja.bugzilla)
yes, it's not an issue, closing as invalid
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.