Sync issues Safari ⇔ Chrome about y-webrtc HOT 5 OPEN

I was having a similar issue. I replaced the y-webrtc implementation with a stub based on @disarticulate's fork (see also #23) and was able to debug more easily.

One of the things I was seeing was:

Failed to execute 'send' on 'RTCDataChannel': RTCDataChannel.readyState is not 'open'

This was happening fairly consistently when a Safari based client would attempt to join a room with Chrome-based clients.

I looked around for connected issues:

• RTCPeerconnection failed on mobile device and on Mac
• https://stackoverflow.com/questions/22470291/rtcdatachannels-readystate-is-not-open
• https://stackoverflow.com/questions/38986297/failed-to-execute-send-on-rtcdatachannel-rtcdatachannel-readystate-is-not

And these helped. Though I haven't fully solved it, I'll keep some notes here: something about the order/state between the two browsers is inconsistent. Chrome <-> Chrome is working well Safari <-> Safari is working well. I tried setting filterBcConns: false when creating the provider to see if it was a broadcast channel problem (this did not help). I removed all crypto (this did not help). I updated simple-peer and Int64 deps (from @disarticulate's version, this did not help).

I'll note that I am dealing with very small documents - chunking was not the problem.

I tried adding two additional checks for this.connected:

    this.peer.on("error", (err) => {
      log("Error in connection to ", logging.BOLD, remotePeerId, ": ", err)
      // THIS LINE IS IMPORTANT WHEN RECONNECTING
      if (!this.connected) return
      announceSignalingInfo(room)
    })

And

    this.peer.on("data", async (data) => {
      const valid = await validMessage(room, data.slice())
      if (!valid)
        return console.warn("!InvalidData", {
          peer: this.peer,
          context: this,
          room,
          data,
        })
      const answer = readPeerMessage(this, data)
      //JEFF: THIS LINE IS IMPORTANT WHEN SETTING UP CONNECTIONS
      if (!this.connected) return
      if (answer !== null) {
        sendWebrtcConn(this, answer)
      }
      return
    })

Which in y-webrtc is here: https://github.com/yjs/y-webrtc/blob/master/src/y-webrtc.js#L228-L237

This fixed almost everything. I also have a heavily offline app that refetches on focus and this really made it feel solid.

The only thing this isn't solving for me is when the browser is offline (not connected to a network provider, navigator.onLine is false... faking it in the Network panel is not enough). In that case the browsers go back to not being able to talk to each other. I see more invalid message errors so an additional check might be needed.

Some conclusions: sending a message when not connected properly crashes the Peer. It goes away entirely and you have to refresh to fix it. But you have to do this to all of the peers and build it up again. If you have an application that refreshes on focus (especially with HMR) this gets very difficult to debug.

I'm interested to know if the this.connected checks feel right. If so I'm happy to open a PR.

from y-webrtc.

A good first start would be to reproduce the issue and check the logs. This issue might also get fixed by simply updating simple-peer.

from y-webrtc.

Just going through this issue, it seems Safari might have issues with their Webrtc implementations.
(feross/simple-peer#672 (comment), https://bugs.webkit.org/show_bug.cgi?id=198545).

Will try a bunch of safari version as soon as possible.

from y-webrtc.

hey, have there been any news on this?
I noticed this behavior while syncing my app data from my laptop(Windows with Brave) to my phone(iOS with Safari)
it does sync fine when you just boot it up, but after some time the connection is lost
and the only remedy is to restart the app

from y-webrtc.

Hey, are you sure this issue is limited to Chrome and Safari? I couldn' t get cross browser syncing to work at all. I tested with Safari, Arc and Chrome.

This issue might be related to #63 and #53

from y-webrtc.