Re: Firefox issue on latest version

162 views
Skip to first unread message

Michelle Bu

unread,
Apr 1, 2013, 2:27:33 PM4/1/13
to port...@tcd.ie, peerjs
Hi there,

Thanks for the support and going forward and testing out Firefox. There are definitely some issues there that I haven't uncovered yet. (So I can try to repro:) are you creating the two connections (one to two and one to three) simultaneously or are you creating one to three after the one to two connection has been established? 

Thanks again!

Michelle


On Mon, Apr 1, 2013 at 11:21 AM, <port...@tcd.ie> wrote:
First of all, amazing work with the library. It's great.

I have an implementation working on Chrome but now I am trying to port it to Firefox using the latest version of the library.

It is working with two peers, but when I try to connect a third peer with the first peer it does not work. The onOpen event is not fired on the third peer. This is the log in the third peer:

[19:16:22.609] PeerJS:  Socket open
--
[19:16:28.949] PeerJS:  Creating RTCPeerConnection
[19:16:29.132] PeerJS:  Listening for ICE candidates.
[19:16:29.133] PeerJS:  Listening for data channel
[19:16:29.133] PeerJS:  Setup Firefox `onconnection`.
[19:16:29.134] PeerJS:  Additional media stream for Firefox.
[19:16:32.465] PeerJS:  Created offer.
[19:16:32.470] PeerJS:  Set localDescription to offer
[19:16:36.816] PeerJS:  Set remoteDescription: ANSWER
[19:16:36.816] PeerJS:  Peer ANSWER received, connectDataConnection called.

I do not get error messages in the first peer or in the server. Both are in debug mode.

The server is running the last version in the repository (with Firefox support). I have also tried it with your cloud server and I got the same results.

I am aware that I am using a not stable version of your library so I really appreciate a bit of help to know what is going on.

Thank you!

Michelle Bu

unread,
Apr 1, 2013, 3:34:00 PM4/1/13
to port...@tcd.ie, peerjs
I was able to reproduce this bug. Firefox's onconnection is not fired for the second connection, which I can't really pinpoint a reason for right now. Perhaps it has something to do with the connectDataConnection calls and the ports I'm using. I'll look into it more tonight.

Michelle

Chris Ball

unread,
Apr 1, 2013, 3:49:01 PM4/1/13
to Michelle Bu, port...@tcd.ie, peerjs
Hi,

On Mon, Apr 01 2013, Michelle Bu wrote:
> I was able to reproduce this bug. Firefox's onconnection is not fired
> for the second connection, which I can't really pinpoint a reason for
> right now. Perhaps it has something to do with the
> connectDataConnection calls and the ports I'm using. I'll look into it
> more tonight.

By the way, it looks like Firefox Nightly broke PeerConnection API
compatibility today (landing in tonight's Nightly), so you might want
to hold off on the release until peerjs works with those changes.
From Mozilla's #media:

15:37 <cjb> Hi, do we still need to call connectDataConnection(4000,4001);
(with ports flipped) after the changes that landed earlier today?

15:40 <jesup> cjb: Sorry, I need to post something. We landed a
break-protocol/API change last night. connectDataConnection() is
now a stub. You need to call createDataChannel() before
createOffer() for DataChannels to be usable. Eventually we'll
support re-negotation, and then calling createDataChannel after
createOffer will cause onnegotiationneeded to fire.

15:41 <jesup> cjb: you only need to call createDataChannel() once
before createOffer() - so it will include m=application in the offer

15:41 * jesup should make the connectDataConnection throw an
error telling people that for the next week or two before
removing it

15:43 <jesup> also note that the binary protocol on teh wire
changed (IETF86 decision), and so builds before the change and
after won't be able to talk to each other. Also, ondatachannel
now includes an event parameter per the spec, instead of just a
reference to the channel -- function new_channel(event) { channel
= event.channel;}


- Chris.
--
Chris Ball <c...@laptop.org> <http://printf.net/>
One Laptop Per Child

Michelle Bu

unread,
Apr 1, 2013, 3:52:42 PM4/1/13
to Chris Ball, port...@tcd.ie, peerjs
Oh wow, that breaks a lot of stuff, including having multiple DataChannels on the same PeerConnection. This also explains why connectDataConnection no longer works as of today (everything was working fine yesterday when I tested multiple connections).

I will implement the API changes (createDataChannel v. connectDataConnection) tonight since it seems like it's now more consistent with Chrome. As for the multiple DCs on one PC feature of PeerJS, we'll just have to hold off on that and make multiple PCs for now.

Michelle

Michelle Bu

unread,
Apr 1, 2013, 4:00:41 PM4/1/13
to Chris Ball, port...@tcd.ie, peerjs
Actually, my Nightly is updated and helloworld/chat demos still work on it, despite only using connectDataConnection. Not sure what is going on there, if that change is really now reflected in Nightly.

Michelle

Chris Ball

unread,
Apr 1, 2013, 4:02:02 PM4/1/13
to Michelle Bu, port...@tcd.ie, peerjs
Hi,

On Mon, Apr 01 2013, Michelle Bu wrote:
> Actually, my Nightly is updated and helloworld/chat demos still work
> on it, despite only using connectDataConnection. Not sure what is
> going on there, if that change is really now reflected in Nightly.

No, I think it landed in trunk today, so it'll be in tomorrow's Nightly.

Thanks!

pir...@gmail.com

unread,
Apr 1, 2013, 4:21:23 PM4/1/13
to Michelle Bu, Chris Ball, port...@tcd.ie, peerjs
> I will implement the API changes (createDataChannel v.
> connectDataConnection) tonight since it seems like it's now more consistent
> with Chrome. As for the multiple DCs on one PC feature of PeerJS, we'll just
> have to hold off on that and make multiple PCs for now.
>
Hi Michelle, would you be able to document your progress on this topic
and how to use DataChannels in this new way now that Chrome and
Firefox will have (at last! :-D ) the same API? I had problems
previously with Chrome DataChannels because they didn't follow the
specification and decided to leave it some time until things got
improved (I have been having problems with university during last
weeks), so now it would be a good time to take it back :-)



--
"Si quieres viajar alrededor del mundo y ser invitado a hablar en un
monton de sitios diferentes, simplemente escribe un sistema operativo
Unix."
– Linus Tordvals, creador del sistema operativo Linux

Michelle Bu

unread,
Apr 1, 2013, 4:40:12 PM4/1/13
to port...@tcd.ie, peerjs
Awesome news :).

Nightly seems really volatile...perhaps we should hold off on FF release until it gets a lot more stable. It's ridiculous that every Nightly release breaks something or another.

Michelle


On Mon, Apr 1, 2013 at 1:13 PM, <port...@tcd.ie> wrote:
Roll-back to 22.0a1 (2013-03-04) and everything is working now.

I will use this version for the demo. Thank you for your help and again, amazing work!

Michelle Bu

unread,
Apr 1, 2013, 4:41:41 PM4/1/13
to pir...@gmail.com, Chris Ball, port...@tcd.ie, peerjs
@piranna: sure will. Both Chrome and Firefox are equally lacking in adherence to spec it seems. Very unfortunate for us.

Michelle

pir...@gmail.com

unread,
Apr 1, 2013, 6:52:24 PM4/1/13
to Michelle Bu, Chris Ball, port...@tcd.ie, peerjs
> @piranna: sure will. Both Chrome and Firefox are equally lacking in
> adherence to spec it seems. Very unfortunate for us.
>
Thanks Michelle :-)

I agree is sad they don't adhere to the spec and are releasing it so
happily, I had some serious problems updating my polyfill to make it
compatible (almost totally broke my P2P application... :-$ ). it's
really difficult to work this way... :-(

Michelle Bu

unread,
Apr 2, 2013, 10:24:01 PM4/2/13
to pir...@gmail.com, Chris Ball, port...@tcd.ie, peerjs
FYI: while I'm looking more into this I'm taking Firefox support out of master because there are other change I want to push to stable. There's a branch `ff` that you can check out to use the semi-broken Firefox impl.

Michelle
Reply all
Reply to author
Forward
0 new messages