1086270 - After the browser is restarted, a user can't be called before registration happens

Status: RESOLVED WORKSFORME

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

Description

[Paul Silaghi, QA [:pauly]]

A call can't be placed until the server knows that the user is there (that takes ~10 seconds)

Comment 1

[Mike de Boer [:mikedeboer]]

The solution would be to disable the call buttons until registration is done.
We're missing two things, the first being blocking to take on work for this bug:

1. Visual style for the call button when it's disabled. Darrin would have an idea about this, methinks.
2. Visual indicator in the panel that tells the user that the client is in the process of registering with the server.

Comment 2

[Darrin Henein [:darrin]]

Is this about placing outgoing calls or receiving incoming calls? The bug title seems to imply incoming calls, but disabling the call buttons (in the contact list?) seems to address outgoing calls. Maybe its both?

Comment 3

[Mike de Boer [:mikedeboer]]

(In reply to Darrin Henein [:darrin] from comment #2)
> Maybe its both?

Yeah, it's both.

Comment 4

[:shell escalante]

Hi Tarek, just want to validate if we expect the 10 seconds on registration and should do a visual UX for it - or if it's longer than expected.

Comment 5

[Tarek Ziadé (:tarek)]

two things:

- 10 seconds seems very long to me. We need to check it up on our side to see why it's so long
- an UX still sounds like a good idea in case the user experience network issue

Comment 6

[:shell escalante]

Tarek has a good point - will try to see if it's server side - but there are scenarios where this could occur anyhow.  added as blocking the UX design request bugs for Hello (though this is lower than the other priorities currently in queue - need to track in queue.

Comment 7

[Alexis Metaireau (:alexis)]

I don't have the request delay in kibana, but 10s seems a very long time, and I believe that the requests would be killed after this time…

Comment 8

[Darrin Henein [:darrin]]

Clearing needinfo until bug is prioritized and assigned for UX work.

Comment 9

[Mark Banner (:standard8)]

I'm not convinced this is a server issue - Firefox has a built in delay of 5 seconds after start-up before it registers:

http://hg.mozilla.org/mozilla-central/annotate/88adcf8fef83/browser/components/loop/MozLoopService.jsm#l283

This was intended to ensure we're not doing too much as soon as FF starts.

We could consider reducing the delay time, I'm not sure what the general thoughts are from the Firefox desktop side though.

Also having some sort of visual indicator would probably be good anyway (I'm not convinced we need to disable everything, but at least make it obvious).

Comment 10

[Mark Banner (:standard8)]

Oh also, there may be some server induced delays we can't do much about. When we start registering, we have to first connect & register with the push server (connect websocket + several round trips), then we have to register with the loop server itself.

Comment 11

[Paul Silaghi, QA [:pauly]]

This bug also applies in the case of guest users.

Comment 12

[Mark Banner (:standard8)]

(In reply to Paul Silaghi, QA [:pauly] from comment #11)
> This bug also applies in the case of guest users.

This will apply to any incoming call. Outgoing actions aren't affected - we force registration to happen straight away if the panel is opened up, hence starting a call, generating a link will all work fine (there may be a small delay whilst registration happens).

I think for most users, receiving a call within the first 5 seconds of startup isn't really an issue - especially now with rooms being a different sort of model, so this would only really affect incoming direct calls.

Adam, Darrin - I'm tempted to close this as won't fix/wfm, but first I'd like to know your thoughts here.

Comment 13

[Adam Roach [:abr]]

(In reply to Mark Banner (:standard8) from comment #12)
> (In reply to Paul Silaghi, QA [:pauly] from comment #11)
> > This bug also applies in the case of guest users.
> 
> This will apply to any incoming call. Outgoing actions aren't affected - we
> force registration to happen straight away if the panel is opened up, hence
> starting a call, generating a link will all work fine (there may be a small
> delay whilst registration happens).
> 
> I think for most users, receiving a call within the first 5 seconds of
> startup isn't really an issue - especially now with rooms being a different
> sort of model, so this would only really affect incoming direct calls.
> 
> Adam, Darrin - I'm tempted to close this as won't fix/wfm, but first I'd
> like to know your thoughts here.

Yeah, I'm not too worried about incoming calls either.

However, if registration is delayed or fails, I think we want some clearly-visible user indication that outgoing direct calls aren't going to work. Either disable the top-level Hello button, or disable buttons dealing with outbound calls until registration succeeds.

So I think we keep this bug open, get the UX prioritized by PM, and then fix behavior per UX spec.

In my book, this is a minor flaw, so I think it's okay pushing to 37.

Comment 14

[Sevaan Franks [:sevaan]]

Just throwing out an idea here, but could the user still "place the call", and we just artificially play some rings until registration occurs at which point the call goes through, or the call fails if the user is unavailable?

Comment 15

[Mark Banner (:standard8)]

(In reply to Sevaan Franks [:sevaan] from comment #14)
> Just throwing out an idea here, but could the user still "place the call",
> and we just artificially play some rings until registration occurs at which
> point the call goes through, or the call fails if the user is unavailable?

This is for a user receiving the call. If in the narrow time of 5 seconds, the other user isn't available, then we can't do anything about it - it would most likely require extending timeouts and adjusting the push infrastructure to give us notifications of things that happen when we're offline.

Adam's comment that we should display something if registration doesn't complete/is delayed, is a definitely thing we should do.

Comment 16

[Mark Banner (:standard8)]

I think the fact that we've now got a loading indication via bug 1194622, makes this "good enough".

For rooms you can't create a room, nor can you attempt to start a conversation.

If you're really quick then you might make it to the contacts list in time, but seeing the spinner you're most likely going to wait.

We also have changes to the push servers & implementation now, so that once registration kicks in the user should know about any updates - there's also bug 1161710 that will improve this further as well.

Hence closing this as WFM as bug 1194622 has landed in nightly.