Sync issues Safari ⇔ Chrome
dmonad opened this issue · 6 comments
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.
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.
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.
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
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.
Hey, any progress in this issue ?