Simple-peer: Weird behavior in Adjacent Chrome Tabs

Created on 28 Apr 2017 · 9Comments · Source: feross/simple-peer

Hi, I have written an example and the source code is here, these are the steps for reproduce:

Open example in two adjacent Chrome Tabs (I am using Linux Mint 18) and Open the JS console in both. Adjacent Tabs means both are in the same window
Copy Your Offer from first Tab to Remote Offer in second Tab and press Save
Copy the answer from second Tab to first Tab Remote Answer input and press Save button

Expected:

JS console should show CONNECTED in both Tabs

Actual:

Only the offerer Tab show CONNECTED message

Note that if you probe it with Tabs in different windows this works as expected.

bug

Source

carloslfu

👍2

Most helpful comment

Seems self._channel.onopen is not being fired when connecting two tabs in the same window.

What is strange is that self._channel.onmessage is still being fired, hence why @matthewtoast 's solution works.

Created a PR to always fire "connect" before emitting data. This should allow you to use normal data to determine connection, instead of sending many heartbeats (assuming you send data on connect to the other peer).

This is definitely a Chrome bug, and we won't have a real solution until they fix it.

t-mullen on 1 Jun 2017

👍2 ❤1

All 9 comments

My work around, FWIW: Once the offerer (initiator) hears the connected event, have it begin sending a regular 'heartbeat' message. The non-offerer (guest) will begin receiving this data despite never having fired its own connected event (it is connected even though it never says so!). On the non-offerer (guest) side, treat the first 'heartbeat' you receive as a substitute for the connected event.

matthewtoast on 21 May 2017

❤2 👍1

Thanks @matthewtoast

carloslfu on 22 May 2017

I'm also experiencing the same issue. However, I'm running two entirely separate chrome instances:

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --user-data-dir=/tmp/XXX

...which leads me to believe this problem goes further than just neighboring tabs. I know chrome 58 was just released and I see these todos (1, 2) in the source code, but I don't suspect it's related.

SupremeTechnopriest on 1 Jun 2017

Seems self._channel.onopen is not being fired when connecting two tabs in the same window.

What is strange is that self._channel.onmessage is still being fired, hence why @matthewtoast 's solution works.

This is definitely a Chrome bug, and we won't have a real solution until they fix it.

t-mullen on 1 Jun 2017

👍2 ❤1

@RationalCoding thanks for the patch! Ill test it in my fork.

SupremeTechnopriest on 1 Jun 2017

works like a charm, thanks again.

SupremeTechnopriest on 1 Jun 2017

I couldn't find a bug report for this on the Chrome bug tracker. I'm hesitant to add hacks for issues that aren't well understood since we might not be fixing the actual issue.

I noticed a few things:

The initiator peer has trickle disabled, but the other peer leaves it enabled. Probably not the source of the issue, but it's weird -- so I changed them to both set trickle: false since we can't rely on there being exactly two 'signal' events like the code is doing now.
Then I tried this "fixed" code in Chrome Stable (59) and Chrome Canary (61). The issue does not exist in Canary 61.

My changes are here: https://github.com/carloslfu/simple-peer-bug/pull/1

I suppose it's okay to merge https://github.com/feross/simple-peer/pull/180 but we should revert once Chrome 61 becomes stable so we don't keep accumulating hacks in the codebase.