Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(886)

Issue 1634073003: Remove references between RTCPeerConnection and RTCDataChannel. (Closed)

Created:
4 years, 11 months ago by Guido Urdaneta
Modified:
4 years, 10 months ago
CC:
chromium-reviews, blink-reviews, tommyw+watchlist_chromium.org, Taylor_Brandstetter, perkj_chrome, hta - Chromium
Base URL:
https://chromium.googlesource.com/chromium/src.git@master
Target Ref:
refs/pending/heads/master
Project:
chromium
Visibility:
Public.

Description

The underlying WebRTC objects maintain all the needed references. No references are actually needed in the blink layer. BUG=564965 Committed: https://crrev.com/0004ce15cdf065966508c61a5265ae8662e363ed Cr-Commit-Position: refs/heads/master@{#371667}

Patch Set 1 #

Patch Set 2 : Update comment #

Patch Set 3 : Remove RTCPeerConnection reference from RTCDataChannel #

Unified diffs Side-by-side diffs Delta from patch set Stats (+15 lines, -71 lines) Patch
M third_party/WebKit/Source/modules/mediastream/RTCDataChannel.h View 1 2 5 chunks +3 lines, -11 lines 0 comments Download
M third_party/WebKit/Source/modules/mediastream/RTCDataChannel.cpp View 1 2 8 chunks +8 lines, -45 lines 0 comments Download
M third_party/WebKit/Source/modules/mediastream/RTCDataChannelTest.cpp View 1 2 2 chunks +2 lines, -2 lines 0 comments Download
M third_party/WebKit/Source/modules/mediastream/RTCPeerConnection.h View 1 chunk +0 lines, -2 lines 0 comments Download
M third_party/WebKit/Source/modules/mediastream/RTCPeerConnection.cpp View 1 2 4 chunks +2 lines, -11 lines 0 comments Download

Messages

Total messages: 15 (7 generated)
Guido Urdaneta
Hi, PTAL. See bug for a discussion about this change.
4 years, 11 months ago (2016-01-26 18:13:17 UTC) #3
tommi (sloooow) - chröme
lgtm
4 years, 11 months ago (2016-01-26 23:15:58 UTC) #7
commit-bot: I haz the power
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1634073003/40001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1634073003/40001
4 years, 11 months ago (2016-01-26 23:18:16 UTC) #8
commit-bot: I haz the power
Committed patchset #3 (id:40001)
4 years, 11 months ago (2016-01-27 01:08:30 UTC) #10
commit-bot: I haz the power
Patchset 3 (id:??) landed as https://crrev.com/0004ce15cdf065966508c61a5265ae8662e363ed Cr-Commit-Position: refs/heads/master@{#371667}
4 years, 11 months ago (2016-01-27 01:09:31 UTC) #12
Guido Urdaneta
A revert of this CL (patchset #3 id:40001) has been created in https://codereview.chromium.org/1641113002/ by guidou@chromium.org. ...
4 years, 10 months ago (2016-01-28 10:19:45 UTC) #13
Taylor Brandstetter
On 2016/01/28 10:19:45, Guido Urdaneta wrote: > A revert of this CL (patchset #3 id:40001) ...
4 years, 10 months ago (2016-01-28 18:46:03 UTC) #14
Guido Urdaneta
4 years, 10 months ago (2016-01-29 15:56:59 UTC) #15
Message was sent while issue was closed.
On 2016/01/28 18:46:03, Taylor Brandstetter wrote:
> On 2016/01/28 10:19:45, Guido Urdaneta wrote:
> > A revert of this CL (patchset #3 id:40001) has been created in
> > https://codereview.chromium.org/1641113002/ by mailto:guidou@chromium.org.
> > 
> > The reason for reverting is: It turns out that the underlying WebRTC
> DataChannel
> >  objects does not maintain a reference to the WebRTC PeerConnection, so we
do
> > need to keep the reference in the blink layer.
> > 
> > PS2 was the correct patch..
> 
> Are you reverting this because it broke anything? The webrtc::DataChannel
> doesn't directly have a reference to a PeerConnection, for design reasons; it
> has a DataProviderInterface. And the creator of the DataChannel
(PeerConnection)
> calls OnTransportChannelDestroyed when the DataProviderInterface is no longer
> safe to use. If this mechanism isn't working, I'd consider it a bug at the C++
> level.

There were concerns that we should have had the strong reference to
RTCPeerConnection in RTCDataChannel.
Nevertheless, we discussed this again and decided that we should reland this and
implement the strong reference in the libjingle layer.

Powered by Google App Engine
This is Rietveld 408576698