UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.95 Safari/537.36

Steps to reproduce the problem:
I bought a new Macbook Pro with touchbar at the end of 2016, the same things still happened to avoid my laptop to go to sleep. I've check with the previous threads and test with my browsers, here are my findings:
-----------------------------------------
2017/1/19
MacOS Sierra Version 10.12.2 (16C67)
Chrome Version 55.0.2883.95 (64-bit)
Safari Version 10.0.2 (12602.3.12.0.1)
Firefox Version 50.1.0
Three test websites all caused Chrome to prevent sleep: from my finding and also this thread
-----------------------------------------
1. http://www.investopedia.com/news/cisco-strengthens-partnership-ericsson/

"pmset -g assertions"
   pid 174(coreaudiod): [0x0000a7d500018e76] 01:24:34 PreventUserIdleSystemSleep named: "com.apple.audio.AppleHDAEngineOutput:1F,3,0,1,1:0.context.preventuseridlesleep" 
	Created for PID: 578. 
   pid 578(Google Chrome): [0x0000009600018124] 36:29:07 NoIdleSleepAssertion named: "WebRTC has active PeerConnections" 

2. http://mashable.com/2014/05/27/micah-lee-greenwald-snowden/ (from:Comment 27 by alexche...@gmail.com, May 16 2014)

Same result as #1

3. http://thenextweb.com/apps/2014/05/11/insane-jailbreak-tweak-brings-multitasking-support-ipad/ (from: Comment 28 by csa...@gmail.com, Jun 6 2014)

"pmset -g assertions"
   pid 168(mds_stores): [0x0000cbf0000b98a7] 00:00:01 BackgroundTask named: "com.apple.metadata.mds_stores.power" 
   pid 382(useractivityd): [0x0000cbee000198a6] 00:00:02 PreventUserIdleSystemSleep named: "BTLEAdvertisement" 
   pid 578(Google Chrome): [0x0000cbea000598a5] 00:00:07 NoDisplaySleepAssertion named: "Playing video" 

All these websites will cause the "Preventing Sleep" flag from Chrome in Energy Monitor, and I've check the source of #1 & #2, both have exact the same WebRTC part in javascripts, 
#1
...
{type:"offer",sdp:"v=0\r\no=- 7745999191240241858 2 IN IP4 127.0.0.1\r\ns=-\r\nt=0 0\r\na=msid-semantic: WMS\r\nm=application 9 DTLS/SCTP 5000\r\nc=IN IP4 0.0.0.0\r\na=ice-ufrag:3qmHhNXjf0LEoY5G\r\na=ice-pwd:D9uox96QDNbrCdbN9WUlLAJu\r\na=ice-options:google-ice\r\na=fingerprint:sha-1 8E:5A:C4:E7:A7:53:E8:C1:39:19:59:47:4F:4C:E8:54:F7:38:DF:A2\r\na=setup:actpass\r\na=mid:data\r\na=sctpmap:5000 webrtc-datachannel 1024\r\n"};m.info("SETTING HARD CODED offer data : "+e.sdp);var n=new S(e);this.peerConnection.setRemoteDescription(n,c.bind(this),this.handleError),c.bind(this)}function c()
...

#2
...
{type:"offer",sdp:"v=0\r\no=- 7745999191240241858 2 IN IP4 127.0.0.1\r\ns=-\r\nt=0 0\r\na=msid-semantic: WMS\r\nm=application 9 DTLS/SCTP 5000\r\nc=IN IP4 0.0.0.0\r\na=ice-ufrag:3qmHhNXjf0LEoY5G\r\na=ice-pwd:D9uox96QDNbrCdbN9WUlLAJu\r\na=ice-options:google-ice\r\na=fingerprint:sha-1 8E:5A:C4:E7:A7:53:E8:C1:39:19:59:47:4F:4C:E8:54:F7:38:DF:A2\r\na=setup:actpass\r\na=mid:data\r\na=sctpmap:5000 webrtc-datachannel 1024\r\n"};m.info("SETTING HARD CODED offer data : "+e.sdp);var n=new S(e);this.peerConnection.setRemoteDescription(n,c.bind(this),this.handleError),c.bind(this)}function c()
...

What is the expected behavior?
It should works like Safari and Firefox. 

What went wrong?
Mac doesn't sleep and drain batteries. 

Did this work before? N/A 

Chrome version: 55.0.2883.95  Channel: stable
OS Version: OS X 10.12.3
Flash Version: Shockwave Flash 24.0 r0

Comparions and Findings:
a. In Chrome, all of these sites will cause "Preventing Sleep" flag gone "Yes", no matter the tab are in use or in back-ground. 
b. In Safari, all of these sites will cause "Preventing Sleep" flag stayed "No"
c. In Firefox, only the #3 will cause "Preventing Sleep" flag gone "Yes", but once the tab gone back-ground, the flag goes back "No"
"pmset -g assertions"
   pid 4857(firefox): [0x0000ce05000598f3] 00:00:21 NoDisplaySleepAssertion named: "screen" 
d. In Chrome, if I go "settings"-"Privacy"-"Content Settings..."-"JavaScript" and block javascript, #1 & #2 which runs WebRTC will NOT cause "Preventing Sleep" flag gone "Yes" anymore. But #3 still remain the same. 

I don't know how Safari handles this, but seems like Firefox has a better mechanism to control this situation. Hope Chrome could solve this problem on Mac, disable javascript is not a good solution to me. 

Jesse Chao
2017.1.19