{"action":"closed","issue":{"url":"https://api.github.com/repos/freedomjs/freedom/issues/251","labels_url":"https://api.github.com/repos/freedomjs/freedom/issues/251/labels{/name}","comments_url":"https://api.github.com/repos/freedomjs/freedom/issues/251/comments","events_url":"https://api.github.com/repos/freedomjs/freedom/issues/251/events","html_url":"https://github.com/freedomjs/freedom/issues/251","id":66198610,"number":251,"title":"core.rtcdatachannel can lose the first messages","user":{"login":"bemasc","id":191945,"avatar_url":"https://avatars.githubusercontent.com/u/191945?v=3","gravatar_id":"","url":"https://api.github.com/users/bemasc","html_url":"https://github.com/bemasc","followers_url":"https://api.github.com/users/bemasc/followers","following_url":"https://api.github.com/users/bemasc/following{/other_user}","gists_url":"https://api.github.com/users/bemasc/gists{/gist_id}","starred_url":"https://api.github.com/users/bemasc/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/bemasc/subscriptions","organizations_url":"https://api.github.com/users/bemasc/orgs","repos_url":"https://api.github.com/users/bemasc/repos","events_url":"https://api.github.com/users/bemasc/events{/privacy}","received_events_url":"https://api.github.com/users/bemasc/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/freedomjs/freedom/labels/bug","name":"bug","color":"fc2929"},{"url":"https://api.github.com/repos/freedomjs/freedom/labels/in%20progress","name":"in progress","color":"ededed"}],"state":"closed","locked":false,"assignee":{"login":"bemasc","id":191945,"avatar_url":"https://avatars.githubusercontent.com/u/191945?v=3","gravatar_id":"","url":"https://api.github.com/users/bemasc","html_url":"https://github.com/bemasc","followers_url":"https://api.github.com/users/bemasc/followers","following_url":"https://api.github.com/users/bemasc/following{/other_user}","gists_url":"https://api.github.com/users/bemasc/gists{/gist_id}","starred_url":"https://api.github.com/users/bemasc/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/bemasc/subscriptions","organizations_url":"https://api.github.com/users/bemasc/orgs","repos_url":"https://api.github.com/users/bemasc/repos","events_url":"https://api.github.com/users/bemasc/events{/privacy}","received_events_url":"https://api.github.com/users/bemasc/received_events","type":"User","site_admin":false},"milestone":null,"comments":0,"created_at":"2015-04-03T17:55:26Z","updated_at":"2015-04-09T17:42:22Z","closed_at":"2015-04-09T17:42:22Z","body":"In WebRTC, the usage pattern for receiving a DataChannel is as follows:\r\n\r\n1. The `rtcPeerConnection.ondatachannel` listener runs, indicating that the remote peer has opened a new data channel.\r\n2. In the callback, the listener sets the `dc.onmessage` callback to a function that handles incoming messages.\r\n3. As soon as the callback ends, the browser is free to call `dc.onmessage` with a new incoming message.\r\n4. If a message listener is not yet registered, the incoming message event is discarded, and **the message is lost**.\r\n\r\nCurrently, `core.rtcpeerconnection` has an `ondatachannel` implementation that calls `dispatchEvent` to report the existence of a new data channel, but does not register an `onmessage` callback.  Freedom events are dispatched asynchronously, so by the time the event listener learns of the new data channel, incoming messages may already have been received, and dropped.\r\n\r\nThis pathology is easy to trigger in the uproxy-networking CHURN integration tests, but it may also explain some other misbehaviors that have been observed in uProxy.\r\n\r\nI think the most likely solution is to buffer messages received on each new data channel in the core environment until a `core.rtcdatachannel` is allocated, at which point the buffer is immediately drained into `'onmessage'` freedom events."}}