+mlamouri, should be easy to fix if we can plumb the visibility signal to the browser. On desktop we do something similar for audibility; i.e. only non-silent audio will hold a wake-lock. I've wanted this for a while, but I think only recently with the IntersectionObserver work have we had the infra to do so. This would be useful for prioritizing idle suspension too. 

That said, I think the impact is pretty low here and its hard to abuse given the single-tab browsing experience provided by Android and the ability to force off the display. It's possible this is even useful for articles and other content with a slow reading pace. Is not the worst case someone accidentally walks away with their display on? If folks are happily using this in non-abusive manners and we're still a long way from fixing 257511, I'm not sure we should prioritize closing this loophole.

In the past, I have been pushing for a Wake Lock API so people would not have to rely on the video hack. I think it would be fair to prevent websites from taking a wake lock when playing in invisible video but given that it would break some websites, we should probably only do this when the API will be available. Unless we are comfortable breaking valid experiences.

This said, we even if we consider this a VeryBadThing(TM) and want to break it without an API, we would be playing a cat and mouse game because the 1x1 video could be moved in-screen and have something rendered on top. Intersection Observer would mark it as visible as it reports what is on the viewport, not if there if can be hit targeted or visible to the user. If we fix this, then, they can simply move the 1x1 pixel to a place where the colour is consistent and make the video the same colour.

If the wakelock can be acquired for fullscreen case, it should satisfy most of the use cases, right?

When we fix the issue, we should disallow both offscreen and 1x1 (or 1xn) case. Keep screen on for video is part of browser's decision. We should only keep screen on while meaningful size of content is visible to user.

I do not know if the Wake Lock API would be enough for fullscreen only. I guess it's probably true but because we have this easy work around, there might be use cases we do not see and are not aware of. It wouldn't be very easy to check that though. We can record the cases of video playing offscreen but we wouldn't be able to distinguish when it is on purpose and when it is not.

Regarding the size limitation, I wonder how reliable a minimum size will be. I think there is a canonical size we might use somewhere for a meaningful playback but I'm afraid this could create some unexpected side effects as some videos might end up smaller (therefore, it could lead to inconsistencies for developers and users). Dale, do we use something like 200px for watch time purpose?

I'm definitely concerned about the potential for an "arms race" here.  Personally my preferred strategy (based on experience with other breaking changes like this) is:

 0. Add a simple UMA counter to measure the extent of the impact here.  I.e. how many wakelock-seconds-per-user would we save by making the simple fix to this bug (this should inform how much time/care is worth spending in some of the steps below).
 1. Ship the fullscreen-only version of the WakeLock API
 2. Look for usage of libraries like nosleep.js, possibly even use Rappor/UKM to find top sites where users tend to get a bunch of time in invisible-video-based-WakeLock.
 3. Do a bit of outreach to evangelize the new WakeLock API
 4. If we find legitimate use cases / complaints about how our WakeLock implementation is insufficient, iterate on the design and goto #2
 5. Ship a simple fix to this bug (eg. unattached or 1x1 cases)
 6. Watch for reports of regressions and people working around our fix and goto #4
 7. Once all legitimate use cases are addressed by the new API, if we continue to see people working around our fix we can tighten it up.  But hopefully this is unlikely - in contrast to pop-up, vibrate, etc. I can't imagine any real incentive for developers to want to work around it.

We use 200x200 px for that, so perhaps anything less than that in area might be a good metric. Probably PluginPowerSaver team has some ideas on size restrictions here.