My usual browser is the most recent Aurora build for OS X, and I haven't been able to receive calls in Loop/Hello for a few weeks at least. It never really worked well but with different symptoms. Lately the symptoms are 100% reproducible: when somebody calls me they get a call failed and I get absolutely nothing. After asking people in #loop I re-did this on the latest Nightly build with a clean profile and the loop.debug.* prefs enabled. After setting the prefs, I restarted the browser, opened the browser console, and generated a URL for somebody to call me. Their call failed, as usual. The full browser console output is attached. As this is 100% reproducible for me I'm happy to try different things as long as as somebody tells me what to do and can try to initiate calls. Catch me on IRC if you would like me to try something in particular.

I just tried this out with Kartikaya. It looks like the connection to the push server had dropped/failed in some manner. Restarting Firefox was able to restart the push server link and Kartikaya was able to receive an incoming call. There's some existing logging that doesn't appear to be showing up - for the websocket closed notifications, e.g. "Loop Push server web socket closed..." The browser is left open for long periods and days, so the only thing I can think is that the websocket to the push server silently closed, so implementing something like bug 1028869 might help. It would also probably help to have UI for notifying if the websocket/server connection is permanently (or for a period?) down - I think there was some thoughts of UX for this a while ago.

> It would also probably help to have UI for notifying if the websocket/server > connection is permanently (or for a period?) down - I think there was some > thoughts of UX for this a while ago. Darrin, can you clarify this point, or do you know someone who can?

ni-ing Sevaan who is covering this week, but I think one of our generic 'Could not connect' errors should suffice. We do not want to be exposing language like web sockets and push servers to our users.

(In reply to Darrin Henein [:darrin] from comment #3) > ni-ing Sevaan who is covering this week, but I think one of our generic > 'Could not connect' errors should suffice. We do not want to be exposing > language like web sockets and push servers to our users. Yes, I agree. Our errors should be relatively user-friendly. Technical jargon is not going to be useful to most of our users. We should probably review the error strings we currently have, though. RT, do you know where I can find some information on what errors we have strings for?

I restarted my Aurora session yesterday with loop logging enabled after the IRC session with :standard8. Today in my browser console I see this: Loop Push server web socket closed! Code: 2152398868

shell: find the bug where Matej put the strings in

I think this requires a string change -- so I'm moving this to "Fx37?"

Moving this to P2 based on our new priority definitions.

Mark -- I was think we'd use this bug to put up a better error message if the websocket/server connection is down. Does that make sense or do you want to use a different bug?

We should use this one.

Because bug 1055145 introduced automatic retrying, which makes the UX a bit more interesting, particularly since this problem can happen at any point (when no call is in progress, when one is being initiated, or when a call is in progress, ...). One could imagine UX for at least some of these situations with a timer & ability to cancel, kind of like gmail does...

moving to 38 based on time - can consider uplifting if done early/hits bar/low risk. need to define the user story - cases so we can get errors for this. is this tech-debt or just a bug?

Given the extended discussion, I've created bug 1203138 to give us a fresh place that re-summarises the issues and hopefully we can drive it through to completion.