1088346 - Handle "answered-elsewhere" on incoming calls for desktop on Loop

Status: VERIFIED FIXED

(Hello (Loop) :: Client, defect, P1)

Description

[Mark Banner (:standard8)]

Bug 1080491 has added an "answered-elsewhere" reason to the "terminate" message from the websocket.

This is received when an incoming call is answered on a different device.

When a client receives it, it should simply close the conversation window.

Comment 1

[Mark Banner (:standard8)]

Attachment: Handle "answered-elsewhere" on incoming calls for desktop on Loop.

This handles the answered-elsewhere state. Well, in fact I've convinced myself it is safe to treat any terminated call as either:

- cancelled; which closes the window (and happens before a call is accepted)
- failed; which shows "Something went wrong" (and happens after a call has been accepted, e.g. call setup failed)

The dev server has the server-side workings for answered-elsewhere, though note that I've just filed bug 1088351 on an issue in the server relating to this which gives the wrong display.

Comment 2

[Nicolas Perriault (:NiKo`) — needinfo me if you need my attention]

Comment on attachment 8510656 [details] [diff] [review]
Handle "answered-elsewhere" on incoming calls for desktop on Loop.

Review of attachment 8510656 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good, rs=me with comments made over IRC addressed, and those below if proved.

::: browser/components/loop/test/desktop-local/conversation_test.js
@@ +439,5 @@
>                      reason: "timeout"
>                    }, "alerting");
>  
>                    sinon.assert.calledOnce(navigator.mozLoop.stopAlerting);
>                    done();

I think we can get rid of using done() here (and everywhere else where this is unneeded in this file — not 100% sure though).

Comment 3

[Mark Banner (:standard8)]

(In reply to Nicolas Perriault (:NiKo`) — needinfo me if you need my attention from comment #2)
> I think we can get rid of using done() here (and everywhere else where this
> is unneeded in this file — not 100% sure though).

Unfortunately, the use of promises forces us into handling this async state. I've had issues before with promises and trying to avoid the async, and it doesn't work.

Hopefully it'll be better with flux, as we won't need to spread promises around so much - its currently a workaround for getting the model set up correctly, which would be much easier with the conversationStore.

Comment 4

[Mark Banner (:standard8)]

https://hg.mozilla.org/integration/fx-team/rev/826a94d4f2c6

Comment 5

[Mark Banner (:standard8)]

For verification:

- Set up three desktop browsers, two signed into one FxA account, and the third into a different account
-- Until bug 1080491 is deployed, these should use the development environment.

- Make a direct call from the different account to the other first account
- On one of the two browsers, accept the call
- Observe the other browser

Expected results:

- Before bug 1080491 is fixed/deployed:
-- The other browser shows "something went wrong" in the title bar
- After bug 1080491 is fixed/deployed:
-- The window closes on the other browser.

Comment 6

[Maire Reavy [:mreavy]]

Comment on attachment 8510656 [details] [diff] [review]
Handle "answered-elsewhere" on incoming calls for desktop on Loop.

Approval Request Comment
[Feature/regressing bug #]:Handling answering calls when the user is logged in on multiple devices
[User impact if declined]: Client will keep ringing even if the call is answered on another device
[Describe test coverage new/current, TBPL]: unit tests, manual verification
[Risks and why]: No risk outside of Hello , low risk to Hello -- without this, the user needs to manually "cancel" the call on the device in order to stop ringing.  This was found when the server was recently updated.
[String/UUID change made/needed]: No strings

Comment 7

[Maire Reavy [:mreavy]]

[Tracking Requested - why for this release]:
Bug fix needed for multiple device support (Server will be updated soon, prior to Hello release)

Comment 8

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/826a94d4f2c6

Comment 9

[u279076]

Paul, can you please verify this is fixed in the latest Nightly?

Comment 10

[Randell Jesup [:jesup] (needinfo me)]

Forgot to hit submit...
Tested this quite a bit against the dev server with Nightly 10/25 Linux & windows; works as intended.

Comment 11

[Lawrence Mandel [:lmandel] (use needinfo)]

Comment on attachment 8510656 [details] [diff] [review]
Handle "answered-elsewhere" on incoming calls for desktop on Loop.

Aurora+

Comment 12

[Randell Jesup [:jesup] (needinfo me)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/84b30e8c65ea

Comment 13

[Randell Jesup [:jesup] (needinfo me)]

Verified on Aurora nightly 10/26 Linux

Comment 14

[Lawrence Mandel [:lmandel] (use needinfo)]

Comment on attachment 8510656 [details] [diff] [review]
Handle "answered-elsewhere" on incoming calls for desktop on Loop.

Beta+

Comment 15

[Randell Jesup [:jesup] (needinfo me)]

https://hg.mozilla.org/releases/mozilla-beta/rev/67d9122b8c98

Comment 16

[Paul Silaghi, QA [:pauly]]

(In reply to Mark Banner (:standard8) from comment #5)
> Expected results:
> 
> - Before bug 1080491 is fixed/deployed:
> -- The other browser shows "something went wrong" in the title bar
> - After bug 1080491 is fixed/deployed:
> -- The window closes on the other browser.
Using the dev-server, now I see:
-- The window closes on the other browser.
and after 5 sec "Something went wrong" in other 2 browsers
FF 34b4, 36.0a1 (2014-10-28) Win 7
Thoughts ?

Comment 17

[Mark Banner (:standard8)]

(In reply to Paul Silaghi, QA [:pauly] from comment #16)
> Using the dev-server, now I see:
> -- The window closes on the other browser.
> and after 5 sec "Something went wrong" in other 2 browsers
> FF 34b4, 36.0a1 (2014-10-28) Win 7
> Thoughts ?

Can you clarify which browsers are the "other 2"? Did you have 3 browsers logged into the FxA account that you were calling?

Comment 18

[Maire Reavy [:mreavy]]

(In reply to Mark Banner (:standard8) from comment #17)
> (In reply to Paul Silaghi, QA [:pauly] from comment #16)
> > Using the dev-server, now I see:
> > -- The window closes on the other browser.
> > and after 5 sec "Something went wrong" in other 2 browsers
> > FF 34b4, 36.0a1 (2014-10-28) Win 7
> > Thoughts ?
> 
> Can you clarify which browsers are the "other 2"? Did you have 3 browsers
> logged into the FxA account that you were calling?

Also, Pauly -- which browsers were running which versions?

Comment 19

[Paul Silaghi, QA [:pauly]]

Never mind. I've hit again https://bugzilla.mozilla.org/show_bug.cgi?id=1000237#c27, because I tested on a single machine.
Everything's fine in FF 34b4.

Comment 20

[Mark Banner (:standard8)]

Clearing in-testsuite requests for features that are being removed from Hello as part of the user journey work in bug 1209713.