Thanks for filing the issue!

@Reporter: From comment#0 it is understood that the issue seems to be a Feature request rather than a bug, Could you please help us in confirming(Feature/Bug) this, which helps us to triage it further in a better way.
Note: Tentatively adding component "Blink>WebRTC" please change if this isn't apt.

1) I consider a silent error a bug--even if some new features need to be added to resolve it.
2) I'm concerned that if this gets treated as a Blink>WebRTC feature-request issue it will just get triaged away to low importance and buried, but if it remains as a UI *bug* it might actually get some traction.

I leave the decision to you guys though.

I'll add that I don't really see this as a problem with the underlying webrtc features themselves, just with how those features are (or not in this case) exposed via the UI for visibility and/or control.

Thank you for providing more feedback. Adding the requester to the cc list.

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

chrome://webrtc-internals shows which url of any page opening a peerconnection, surely that helps discovering which tab causes this?

no, it does not solve the problem. please reread the report.

I discern at least 3 requests within this ticket:

- Expand webrtc-internals to allow jumping to the tab owning the connection
- Allow a page to enumerate all PeerConnections created in <some context, probably page>
- Reevaluate the relationship between PeerConnections and power saving functions

There may be more.

These should probably be separated into separate bugs, and triaged appropriately.

Without spec redesign, we can't get around the fact that non-closed PCs are "active" and non-garbage collectable.

I don't think the user should have to manually hunt down which page has a PC and manually intervene to the application logic to close it. That would be addressing the symptoms (in a way that a normal user would never engage) without addressing the underlying problem.

Since PCs can be used outside of the context of actively sending and receiving, and any page could have them lying around (not just obvious video conference pages), I think we should definitely reevaluate the relationship between RTCPeerConnections and power saving functions.



Can we simply not inhibit power savings?

Are we explicitly inhibiting it, or is this an implicit side-effect of having active connections?

Can we categorize a connection as "inactive" if data is not sent/received within x minutes?

Do we know if the lockscreen is on or not? I would be fine with closing connections for "inactive" PCs if the lockscreen is on. Of course it would be even better if PCs could be cleaned up better regardless of lockscreen.

We don't know, perhaps the PCs are "active", in which case we should think about closing even active connections when lock screen is used.

Needs further discussion and knowing background of the power saving functions. Do we know who to ask?

While you are investigating and discussing the much more complex issue of power savings inhibitions, simply adding the visibility to the webrtc-internals page allowing anyone to track down the source page/tab of any PC not only helps mitigate the immediate symptom, but may also be a useful debugging aid as well.

I see two underlying problems:
1) that the browser assumes it understands the purpose/use case of a PC and the intention of the user to know when inhibiting power savings should occur (if even ever--I suspect the browser should *never* inhibit power savings--that it can't possibly ever have the requisite visibility to properly decide)
2) that the browser could assume that a "normal" user wouldn't/shouldn't want to engage in controlling how and when any page is allowed to initiate PCs. PCs are a resource and a potential security risk. Thus just like popups and cookies they should have the similar, visible controls such as "always ask/never/once"

To point #2, the mere existence of extensions attempting to disable webrtc proves that users *are* interested in finer grain control.

#17: Why can't you use chrome://webrtc-internals/ to track down the source pages already? It shows you every PC that exists - a separate stats page for each of them, the title of the page saying the source URL. That should be enough to know which tab(s) to close?

I think revising the permission model for whether or not a site is allowed to create a PCs in the first place is an independent issue from PCs that do exist preventing power savings and should be discussed separately.

Where is the separate stats page for each one and where is the title of the page with the source URL??
I have never seen these despite poking around a lot. If they do exist, maybe they just need better visibility?
Just having the URL of the PC itself doesn't help--it's usually caused by an ad  served from a different domain.

https://photos.app.goo.gl/irkz9yfYqCnahmeH8 shows how https://webrtc.github.io/samples/src/content/peerconnection/munge-sdp/ has created an RTCPeerConnection (two actually, the first one being the selected page) after I pressed the "Get media" button followed by "Create peer connection" (before that chrome://webrtc-internals/ was empty).

Of course that page also renders the web cam's video, and if you press all the buttons on that page in sequence it will create a loop-back video call, a very "active" use of PCs.
For just a dummy PC you can open up the developer console and type in "const pc = new RTCPeerConnection()" and that should also create a page inside of chrome://webrtc-internals/ for that PC. Does that - an "inactive" peer connection - inhibit power saving for you?

If power saving is inhibited, but chrome://webrtc-internals/ does now show any peer connections, then I think the power saving issue you are experiencing is not related to RTCPeerConnection but should nonetheless be investigated. Can you check?

Also you might be right about the URL if it shows the ad domain and not the parent page domain, but it might show the URL of interest - I don't know. Can you check?

https://photos.app.goo.gl/hNj32cTLPZ9UBZSU8

I haven't duplicated the original state yet, since I restarted chrome my adblocking has been working and the PCs to the ad network hasn't reopened--so I'm still not sure what type of connection it was nor the originating page.
As soon as it happens again I'll check.

Okay, it's happened again to me.
Tell me where in that info it shows the tab/page that is the originator of the connection.
This is with:
Chrome 68.0.3440.106 (Official Build) (64-bit)

I do not have any tab/page open to the same domain as the PCs.

Deleted: Screenshot_20180812_131803.png 159 KB

	Screenshot_20180812_131803.png 159 KB View Download

I've been hitting this on a few pages, most recently ( https://www.tomshardware.com/reviews/razer-core-v2-external-graphics-enclosure,5598-2.html ). That page loads script from an ad network ( https://static.adsafeprotected.com/sca.17.4.95.js ) that includes this weird snippet:

```

if ("function" == typeof RTCPeerConnection)
    try {
        var a = new RTCPeerConnection;
        if ("object" == typeof a.localDescription && "object" == typeof a.remoteDescription && "string" == typeof a.signalingState && "string" == typeof a.iceGatheringState && "object" == typeof a.onremovestream && "object" == typeof a.onicecandidate)
            try {
                mozRTCPeerConnection();
                return !1
            } catch (a) {
                return !0
            }
    } catch (a) {}
return !1
```

Since the code doesn't call close() and leaks the reference, the machine stays awake as long as the page is loaded.

I strongly agree with hbos@ assertion in #16 that "we should definitely reevaluate the relationship between RTCPeerConnections and power saving functions". To answer a few questions from that same comment:

> Can we simply not inhibit power savings?

Probably? At the very least, Chrome should be keeping the machine awake because of some activity the user cares about, like video or audio or data transfer.

> Are we explicitly inhibiting it, or is this an implicit side-effect of having active connections?

It's explicit: https://cs.chromium.org/chromium/src/content/browser/webrtc/webrtc_internals.cc?l=562&rcl=19d33c77a4173b7768bc3f7a3920a744e8b22eed

> Can we categorize a connection as "inactive" if data is not sent/received within x minutes?

Or if there is no established connection, as is the case when you just run:
`let a = new RTCPeerConnection()`
and run away.

> Do we know if the lockscreen is on or not? I would be fine with closing connections for "inactive" PCs if the lockscreen is on. Of course it would be even better if PCs could be cleaned up better regardless of lockscreen.

If we're willing to close connections when the machine is locked, it's easier to just not keep the machine awake to start with. The connections will close naturally when the OS decides it's time to sleep. :)

Thanks for the code! That is one contributor to a puzzling pattern we've seen of PeerConnections that are started and never used.

The code seems to be looking for a Mozilla/Chrome difference, but it's a weird way to do that (both have implemented RTCPeerConnection, but only Mozilla has the "moz" version).

I filed  crbug.com/875634  for the specific issue of not inhibiting suspend when connections aren't connected. That seems like an obvious "we should do that no matter what else".

#26: Thanks a lot!

#25: The URL would be https://jbbchheh.edvfwlacluo.com/... and so on but that does not wound like a real tab's URL.

That's what I've been saying, that the URL configured for the PC doesn't have any relation to the URL of the tab invoking the code that creates the PC.

So, hours after a video conference using google meet, this lingers on my webrtc internals page, *and* I kill'd the process with pid 5087, this remains, impeding power savings: (The window used for the conference was long since closed also)

Caller origin: https://meet.google.com
Caller process id: 5087
Audio Constraints
{deviceId: {exact: ["default"]}, advanced: [{googEchoCancellation: {exact: true}}, {googExperimentalEchoCancellation: {exact: true}}, {googAutoGainControl: {exact: true}}, {googExperimentalAutoGainControl: {exact: true}}, {googNoiseSuppression: {exact: true}}, {googExperimentalNoiseSuppression: {exact: true}}, {googHighpassFilter: {exact: true}}, {googAudioMirroring: {exact: true}}]}
Video Constraints

Interesting, so the RTCPeerConnection was legitimately used for things but for some reason not garbage collected. I tried hangouts and meet myself but I'm unable to reproduce this, navigating away from the removes it for me.

leippe@: What you are reporting in #31 is an active getUserMedia session, which does not prevent power savings.
Maybe you have PeerConnections in addition to that.

This is a huge problem for me. I discovered that Chrome was constantly causing my Macbook battery to go flat in less than 24 hours because WebRTC was preventing sleep the whole time while unplugged with the lid closed.

Here's the offending line in pmset -g assertions:
pid 28380(Google Chrome): [0x00030d4f00018f25] 00:21:00 NoIdleSleepAssertion named: "WebRTC has active PeerConnections" 

The issue is that many pages which don't require RTC are using WebRTC. For example:
- https://www.finder.com.au/american-express-explorer-credit-card
- https://account.t-mobile.com/oauth2/v1/chooseSecondFactor

Given that any random site could potentially cause my Macbook to not sleep and drain my battery, Chrome really should not be preventing sleep just because WebRTC is active. Is there a way to differentiate between these rogue uses of WebRTC and a legitimate use (e.g. when I'm in an active Hangouts call)? Or would it be reasonable to just disable NoIdleSleepAssertion entirely for WebRTC?

I have now switched my browser to Safari because it doesn't have the same bad behaviour on the above sites.

Deleted: Screen Shot 2018-10-25 at 09.31.23.png 1.0 MB

	Screen Shot 2018-10-25 at 09.31.23.png 1.0 MB View Download

FYI, Slashdot's main page now creates a webrtc connection. This is new as of a only about a week. This is getting more and more widespread.

Notes: Seems like we can get better behavior out of the suspend thing by only refusing suspend if there's an active connection.

Transition to watch: ICE state changes, injected via PeerConnectionTracker::IceStateChange:

https://cs.chromium.org/chromium/src/content/renderer/media/webrtc/peer_connection_tracker.cc?type=cs&g=0&l=830

From the three features that could be inferred from this bug

1. Expand webrtc-internals to allow jumping to the tab owning the connection
2. Allow a page to enumerate all PeerConnections created in <some context, probably page>
3. Reevaluate the relationship between PeerConnections and power saving functions

We are focusing on (3). The plan is to block power saving only with peer connections that have actually established a connection. The current mechanism is too aggressive since merely creating a peer connection blocks power saving.

We believe that if we get (3) right, (1) and (2) become less important, so for now, we will not work on them. If the need arises after the improvements for (3), we can file separate bugs.

(1) seems useful regardless of the progress of (3). Adding a link/url/even just title sounds rather simple--unless it is complicated to access the tab's url/title from the internal context that the webrtc-internals page has access to?

Addressing (1) is not so trivial and will probably less needed if (3) works according to the recommendation in #37, which we are implementing.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0bc103ac42ee5fd6e92577dfcf391965dedd5420

commit 0bc103ac42ee5fd6e92577dfcf391965dedd5420
Author: Guido Urdaneta <guidou@chromium.org>
Date: Fri Nov 16 19:54:33 2018

Update WakeLock policy for RTCPeerConnections.

This CL changes the policy so that the WakeLock is enabled only when an
RTCPeerConnection becomes connected.
Previously the WakeLock was enabled as soon as the RTCPeerConnection was
created. This caused problems for some users, since some sites create
peer connections that are never connected and are only closed when the
peer connection is removed.

Bug:  866200 
Change-Id: I47e573f9555960c1a64a0f9834afb9d5dc048a94
Reviewed-on: https://chromium-review.googlesource.com/c/1315210
Reviewed-by: Henrik Boström <hbos@chromium.org>
Reviewed-by: Harald Alvestrand <hta@chromium.org>
Commit-Queue: Guido Urdaneta <guidou@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608905}
[modify] https://crrev.com/0bc103ac42ee5fd6e92577dfcf391965dedd5420/content/browser/webrtc/webrtc_internals.cc
[modify] https://crrev.com/0bc103ac42ee5fd6e92577dfcf391965dedd5420/content/browser/webrtc/webrtc_internals.h
[modify] https://crrev.com/0bc103ac42ee5fd6e92577dfcf391965dedd5420/content/browser/webrtc/webrtc_internals_unittest.cc

Is this sufficient?
It will reduce the number of PCs that affect power savings, but this still doesn't provide a way for a user to forcibly close a PC, or even find the tab creating one to close it.

 Issue 875634  has been merged into this issue.

Closing this for now. 
Let's test this fix to see if power savings is still an issue in practice.
If so, we can reassess if we need to extend webrtc-internals.