1114846 - Rooms store should update the local version immediately in cases where the action is unlikely to fail

Status: RESOLVED INCOMPLETE

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

Description

[Matthew N. [:MattN]]

In bug 1113574 there was a problem with race conditions and how the Rooms store is updated. The following scenario seems to be quite reproducible by agibson:

User A is using the built-in Loop UI while User B is using the standalone UI.

1) User A opens a room
2) User A copies the URL and sends to User B
3) User A closes the Room window/chat. The `leave` method is called.
4) User B joins the room.
5) User A receives push notification for the join and update it's local store. The room now has both participants even though User A already left.
6) Server updates room data on server for the leave. User A's local store is stale but not marked as such.
7) User A receives the push to update it's room store from the server to only have on participant (User B).

After step 3 until step 7, the client and UI still indicates that User A is in the room even though they closed it. This doesn't lead to a good UX since the toolbar button color and blue dot in the room list are incorrect for sometimes up to 20 seconds.

IMO, at least for requests which aren't likely to cause problems if they fail, we should update the local store and dispatch the notifications immediately so the UI reflects the real current state of the Firefox user. Having a delay for both the push notification and then the HTTP request to the Loop server is way larger than the 1 second that I think would be appropriate based on http://www.nngroup.com/articles/powers-of-10-time-scales-in-ux/

Comment 1

[Mark Banner (:standard8)]

(In reply to Matthew N. [:MattN] from comment #0)
> After step 3 until step 7, the client and UI still indicates that User A is
> in the room even though they closed it. This doesn't lead to a good UX since
> the toolbar button color and blue dot in the room list are incorrect for
> sometimes up to 20 seconds.

We shouldn't be seeing 20 second delays now - the new loop-server that got pushed on Friday should have fixed that. If you see anything more than a second or so, please file a separate bug on it.

Comment 2

[Maire Reavy [:mreavy]]

Mark, MattN, Mike --- Do we need to address this bug in the short term or longer term?  

It sounds like the pain was due to a long server delay that has been greatly improved/fixed.  I'd appreciate your thought on where this should be triaged and how important it is.

Comment 3

[Mark Banner (:standard8)]

I'd say fix it when we can get to it in the 38 cycle, and let it ride the trains or uplift as appropriate.

Comment 4

[Maire Reavy [:mreavy]]

Let's mark it for Fx38+, P2.  Matt, Mike -- If you object to this, please chime in on this bug.

Comment 5

[Matthew N. [:MattN]]

I think part of the problem in this bug is that it's possible to leave the room too early and lead to the UI still thinking you are a participant for a long time after you're not.

Comment 6

[:shell escalante]

drop in priority based on server patch that greatly resolved the issue - no reason to believe as severe as when filed.  may be a couple of second delay - versus 20 second at time of filing.  will raise priority if reports of it being a bigger issue still.

Comment 8

[Mark Banner (:standard8)]

Support for Hello/Loop has been discontinued.

https://support.mozilla.org/kb/hello-status

Hence closing the old bugs. Thank you for your support.