Sync issues Safari ⇔ Chrome

[dmonad]

This is a great issue for people who wish to contribute #helpwanted

Describe the bug Chrome and Safari don't sync

To Reproduce See issue description: https://discuss.yjs.dev/t/problem-with-webrtcprovider-connect-after-disconnect/278

Expected behavior Safari keeps up with Chrome

Environment Information

• Unknown

Additional context This is probably an issue internal to simple-peer - the webrtc module that is used in y-webrtc.

[dmonad]

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.

[froger]

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

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

[snqb]

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

[jeffrafter]

I was having a similar issue. I replaced the y-webrtc implementation with a stub based on @disarticulate's fork (see also https://github.com/yjs/y-webrtc/issues/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.

[tim-hilt]

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