New issue
Advanced search Search tips

Issue 795865 link

Starred by 5 users

Issue metadata

Status: WontFix
Owner:
Closed: Feb 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment

Datachannel fails to receive file

Project Member Reported by philipp....@googlemail.com, Dec 18 2017

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/63.0.3239.84 Chrome/63.0.3239.84 Safari/537.36

Steps to reproduce the problem:
1. go to https://simplewebrtc.com/filetransfer
2. click "create it"
3. copy url, open in second tab
4. in second tab (same window!), wait for the peerconnection to become connected
5. select a (small) file to be sent to the first tab
6.the first tab never receives the file

Now close the second tab, open a new window, repeat steps 3-5. In step 6 a file will be offered for download in the initial tab

What is the expected behavior?
things just work

What went wrong?
something. I did some bisecting and steps 1-6 still worked in M56 + M57. 

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 63.0.3239.84  Channel: n/a
OS Version: 
Flash Version:
 
I don't see much difference between the two logs (--enable-logging=1 --v=4) for the working case (worky.log) and the case that does not not work (no-worky.log)

From what I can see dc.onmessage is not called but that doesn't seem to be in the log.
no-worky.log
1.9 MB View Download
worky.log
1.8 MB View Download
note that the js code reattaches dc.onmessage inside onmessage: https://github.com/andyet/SimpleWebRTC/blob/master/src/peer.js
this might be... unexpected.

Comment 3 by rje...@webrtc.org, Dec 19 2017

> this might be... unexpected.

Perhaps... but it should absolutely work (and I can see cases where one would modify the callback to the processing code depending on the data in the current message).

Comment 4 by guidou@chromium.org, Dec 19 2017

Cc: guidou@chromium.org
Components: -Blink>WebRTC Blink>WebRTC>PeerConnection
Owner: hbos@chromium.org
Status: Assigned (was: Unconfirmed)
hbos@: Can you take a look at this?

Comment 5 by hbos@chromium.org, Dec 19 2017

Is peer.js all the relevant code or is there more? jsfiddle would be nice.
its a quite complicated app (despite the name) :-)

https://github.com/otalk/filetransfer/blob/master/filetransfer.js#L79 has the receiver logic but afaics that doesn't even get called.
https://github.com/otalk/RTCPeerConnection/blob/master/rtcpeerconnection.js#L894 is a wrapper around peerconnection but it seems to be emitting the datachannel event properly.

So far I have not managed to reproduce inside a fiddle
It seems that I am also able to reproduce it on my application with Chrome 63 on Mac.
I have done a quick test on Mac with Chrome 62 and it was working.
It seems that the first sended packets are lost so if the file is small nothing is received on other side.
It was working for me upto yesterday.
Found the issue only yesterday.

Comment 9 by hbos@chromium.org, Dec 28 2017

I have not had time to look at this yet.
Here's another data channel issue, may or may not be related: https://crbug.com/792317
Any movement on this?

Comment 11 by hta@chromium.org, Feb 15 2018

Summary: Datachannel fails to receive file (was: datachannel)
Changed subject to make it easier to distinguish

Comment 12 by hbos@chromium.org, Feb 15 2018

Not yet, is this repro case doing something special? I assume DataChannel is not completely broken, hence having prioritized other things.

Comment 13 by hbos@chromium.org, Feb 15 2018

A jsfiddle or more details would be nice.
I can no longer reproduce in M64 or M66. Can you #10?
I cannot reproduce between Chrome 64+ to Chrome 64+.

I can reproduce between Chrome and Safari but dealing with Safari compatibility issues might be out of the scope of this issue

Was referred by this SimpleWebRTC issue: https://github.com/andyet/SimpleWebRTC/issues/664

Comment 16 by hbos@chromium.org, Feb 19 2018

Status: WontFix (was: Assigned)
Maybe this was an issue fixed in third_party/webrtc and Safari has not picked up the fix yet.

In any case, if the Chrome-Chrome is not reproducible anymore I'm closing this issue. Thanks everyone.

Sign in to add a comment