Oh, it appears this was actually an intentional change, made due to https://bugs.chromium.org/p/chromium/issues/detail?id=697618. The bug is protected, but in short: an application was doing hundreds of offer/answer negotiations, resulting in a large amount of memory required to store the event log.

So, after this CL (https://codereview.chromium.org/2727233002), the log will only be stored if chrome://webrtc-internals is already open. Was there a PSA about this change? I never thought to try opening webrtc-internals before the offer/answer negotiation; usually I'm opening it after a problem occurs, because I want to explore what happened.

Anyway, I'd like to request a less strict solution to the memory ballooning problem. Such as "only store last 100 entries if webrtc-internals isn't open". It would also be helpful if whatever restriction we end up with is visibly documented on chrome://webrtc-internals, for developers who are used to the old behavior.

Tommi, thoughts? Does my suggestion above seem reasonable?

Looks like the right people have their eyes on this bug, so I'll consider it triaged.

When dropping stuff one needs to have a way to display the current state before the drop which is probably going to be complicated.

The change defeats much of the purpose of webrtc-internals.

I can understand however that this is becoming a problem. How about making webrtc-internals available behind a chrome flag? I've very rarely gotten actual users to send me a dump. Moving the functionality to a (cross-browser) extension is something I've pondered about for quite a while too.

tommi: can you please at least send an email to discuss-webrtc documenting the current state of things?

to make things worse: if you have the page open then closing a peer connection doesn't seem to modify the timeline that is not there. Might be a JS issue...

This also rolled into M59?

Any updates on this bug ? 

Is there any plans to add back the SDP data back to the webrtc-internals ?

this bug is available aka "nobody is working on it right now".
The workaround is to have it open before the call.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Asking hta@ for feedback regarding if this issue can be closed or not.