1072685 - Can't accept loop calls on Nightly

Status: RESOLVED DUPLICATE of bug 1074517

(Hello (Loop) :: Client, defect)

Description

[Richard Pappalardo [:rpapa][:rpappalardo]]

STR
1. Successfully initiated call using FF Nightly (35.0a1) on laptop A [1]
2. emailed link
3. clicked on conversation link on (Mac) laptop B [1]
4. Observed: "Ready to start your conversation: Start"
5. Clicked on: Start button
6. Observed:  "Connecting...' (for half a second)
7. Observed: Start button comes back, but call not initiated 

Note:
One successful call ended abruptly shortly after connecting (within 15 seconds)

[1] Mac - Laptop A
Name: Firefox
Version: 35.0a1
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:35.0) Gecko/20100101 Firefox/35.0
OSX 10.9.4

[2] Mac - laptop B
Name:Firefox
Version 	35.0a1
Update History 	
User Agent 	Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:35.0) Gecko/20100101 Firefox/35.0
OSX 10.9.2

Comment 1

[Richard Pappalardo [:rpapa][:rpappalardo]]

A few more tests and I see that calls are more successful when laptop A (that creates link) allows laptop B to click the link first.  When this happens the call seems to be more likely to go through, but still terminates abruptly.  
When laptop A creates link and initiates call, then laptop B cannot join

Comment 2

[James Bonacci [:jbonacci]]

My testing from earlier today showed FxA/HawkAuth issues on Nightly, but not on Aurora.
Not sure when the DNS was switched over to the new stack, so not sure if this is a Nightly issue or a Loop-Server 0.12.2 issue...

Comment 3

[James Bonacci [:jbonacci]]

I see this in the Browser Console on Nightly:
Security Error: Content at about:looppanel may not load or link to chrome://browser/content/browser.xul#.
"getLoopCharPref had trouble getting ot.guid; exception: [Exception... "Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIPrefBranch.getCharPref]"  nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)"  location: "JS frame :: resource:///modules/loop/MozLoopService.jsm :: this.MozLoopService.getLoopCharPref :: line 1257"  data: no]"

The call starts but does not complete.

On a second attempt it appears to work.

Comment 4

[James Bonacci [:jbonacci]]

This shows up in the terminal (I started Nightly in CLI):
console.log: getLoopCharPref had trouble getting ot.guid; exception: [Exception... "Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIPrefBranch.getCharPref]"  nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)"  location: "JS frame :: resource:///modules/loop/MozLoopService.jsm :: this.MozLoopService.getLoopCharPref :: line 1257"  data: no]
WARNING: no real random source present!

Comment 5

[James Bonacci [:jbonacci]]

I can not reproduce the more nasty FxA/HawkAuth errors I saw earlier...

Comment 6

[James Bonacci [:jbonacci]]

Downgrading right now. :rpapa and the client team can continue to investigate.
This does not appear to be related to the Loop-Client deploy.

Comment 7

[Mark Banner (:standard8)]

I'd just like to clarify some things, as I think you're using slightly different terminology:

(In reply to Richard Pappalardo [:rpapa][:rpappalardo] from comment #0)
> 1. Successfully initiated call using FF Nightly (35.0a1) on laptop A [1]

Normally we've described this as "obtained a call url" - getting a call url, in itself doesn't start the actual call.

> 7. Observed: Start button comes back, but call not initiated 

Finding out what's on the web console (for the standalone clicker ui), is generally helpful in this type of situation.

(In reply to Richard Pappalardo [:rpapa][:rpappalardo] from comment #1)
> A few more tests and I see that calls are more successful when laptop A
> (that creates link) allows laptop B to click the link first.  When this
> happens the call seems to be more likely to go through, but still terminates
> abruptly.

See above, web console output is especially useful at the moment, until we get bug 1000240 fixed.

> When laptop A creates link and initiates call, then laptop B cannot join

This scenario is never going to work. If Laptop A generates and clicks the link, then Laptop A is going to be talking to itself.

Comment 8

[Mark Banner (:standard8)]

(In reply to James Bonacci [:jbonacci] from comment #3)
> "getLoopCharPref had trouble getting ot.guid; exception: [Exception...
> "Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED)
> [nsIPrefBranch.getCharPref]"  nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)" 
> location: "JS frame :: resource:///modules/loop/MozLoopService.jsm ::
> this.MozLoopService.getLoopCharPref :: line 1257"  data: no]"

This is harmless, not an issue (apart from the extra debug msg).

> The call starts but does not complete.
> 
> On a second attempt it appears to work.

It might be useful on the end that generated the link, to set "loop.debug.websocket" to true. On the browser console, you can then see what information is going across the websocket that's used for connecting. So we can see if it times out or not.

This is also possible to debug at the link-clicker end, you have to go into the web console for the page, then enter:

localStorage.setItem("debug.websocket", true);

You might need to reload the page, but after that, it'll keep debugging of the websocket on in that profile (use localStorage.removeItem("debug.websocket"); if you want to remove it).

Comment 9

[Richard Pappalardo [:rpapa][:rpappalardo]]

> When laptop A creates link and initiates call, then laptop B cannot join
>> This scenario is never going to work. If Laptop A generates and clicks the link, then Laptop A is going to be talking to itself.

As a user, I could see joining the room first for the URL I just generated, but since we're moving to the rooms UX anyway, there's probably no need to split hairs on this.  Since this was the main reason I filed this bug, I'll close this one.  
The other issue of call termination is addressed by: Bug 1074517