1118246 - Issues on the standalone page after deleting the active conversation

Status: VERIFIED FIXED

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

Description

[Paul Silaghi, QA [:pauly]]

Attachment: loop delete conversation while active.png

STR:
1. Start latest nightly
2. Disable e10s (otherwise won't be able to make a 1:1 call on the same machine - bug 1109062)
3. Create a new room
4. Copy/paste the URL in Nightly or Chrome and join the call
5. While the call is active, delete the room from the Hello panel

Actual results:
'Leave' button still active, no error message explaining what's happening (ie: the conversation is no longer available), a small rectangle on the bottom right corner.

Comment 1

[Paul Silaghi, QA [:pauly]]

Browser console logs:
"Rumor.Socket: Rumor Socket Disconnected: Used to indicate that a connection was closed abnormally (that is, with no close frame being sent) when a status code is expected. (CLOSE_ABNORMAL)" sdk.js:910:14

"OT.Raptor.Socket: cannot publish until the socket is connected.{"method":"delete","uri":"/v2/partner/44835892/session/1_MX40NDgzNTg5Mn5-MTQyMDU1NDI2NTczNX56bDNJN0ZXTitSRi9BWTdobmZSVEtjWU1-UH4/stream/58557c49-38a3-414d-b193-3f21c19275b2","content":{}}" sdk.js:910:14

no element found ClientEvent:1:1
"Loop hawkRequest error:" Object { code: 404, errno: 105, error: "Token not found." } MozLoopService.jsm:547
Object { code: 404, errno: 105, error: "Token not found." } LoopRooms.jsm:429

Comment 2

[Paul Silaghi, QA [:pauly]]

Also note https://bugzilla.mozilla.org/show_bug.cgi?id=1092954#c32
"NOTE also: if the room is deleted while the standalone user is in the room (but the desktop user is not), nothing appears to happen on the standalone side."

Comment 3

[Mark Banner (:standard8)]

(In reply to Paul Silaghi, QA [:pauly] from comment #2)
> Also note https://bugzilla.mozilla.org/show_bug.cgi?id=1092954#c32
> "NOTE also: if the room is deleted while the standalone user is in the room
> (but the desktop user is not), nothing appears to happen on the standalone
> side."

Yep, we can't do much about that, as there's no easy route for us to do anything here. What will most likely happen is that after approximately 5 minutes, the user will get booted out with information about the link being expired or invalid.

I have a fix in progress for comment 0.

Comment 4

[Mark Banner (:standard8)]

Attachment: Loop should handle forceDisconnect events from the OT sdk.

This gets it working properly. When I originally wrote the sdk driver, I think I wasn't really expecting events with reason forceDisconnected, or if I was, I was expecting them as part of the connectionDestroyed event.

Re-reading the sdk docs, its clear that for the client which is disconnected, the event which happens is sessionDisconnected with reason forceDisconnected - hence this patch adds the extra dispatch. I treat it as an expired/invalid url, as effectively that's what it has become.

Comment 5

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

Comment on attachment 8544606 [details] [diff] [review]
Loop should handle forceDisconnect events from the OT sdk.

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

LGTM.

Comment 6

[Mark Banner (:standard8)]

https://hg.mozilla.org/integration/fx-team/rev/6d5a48fde5fb

Comment 7

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/6d5a48fde5fb

Comment 8

[Paul Silaghi, QA [:pauly]]

(In reply to Mark Banner (:standard8) from comment #3)
> What will most likely happen is that after approximately 5
> minutes, the user will get booted out with information about the link being
> expired or invalid.
The call is still active after 10 min. Probably the same server refresh issue as in bug 1123349.

> I have a fix in progress for comment 0.
Verified fixed 37.0a2 (2015-01-19) Win 7