FWIW, I'm happy for the media team to implement the change if you point to me how we can check that we are in Previews mode in Blink.

There isn't currently a nice way to get at the full PreviewsState for a frame in Blink, at least, not from the places where we'd be able to disable video autoplay, but it wouldn't be too hard to add a way to get at this signal.

Blink can currently determine if Client LoFi is active for a Frame, from LocalFrameClient::IsClientLoFiActiveForFrame(), which plumbs through to RenderFrameImpl::IsClientLoFiActiveForFrame(), so this plumbed method could be changed to just return the raw PreviewsState (and let code in Blink handle the logic that's currently in RenderFrameImpl for determining which previews take precedence over others), or a new plumbed method could be added.

I'd prefer moving as much of the renderer Previews-related logic into Blink as possible, what with the whole Blink onion soup effort in progress, so I'd recommend modifying the existing method.

Is the new plumbing something that you or someone in the Data Saver team could tackle?

Doug, since you are dealing with a bunch of previews plumbing, do you think you could help with this?

What sclittle proposes in Comment 2 sounds like also a solution to  issue 721469  as well.

 Issue 795951  has been merged into this issue.

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

commit db52c3fbcd47c7c02dfe36ef7bc5d8346e0f4a6c
Author: Doug Arnett <dougarnett@chromium.org>
Date: Fri Jan 05 17:13:13 2018

Plumbs PreviewsState into blink for use by intervention code

Replaces the specific IsClientLoFiActiveForFrame() method with a more
general GetPreviewsStateForFrame() method which may be used by other
pieces of interventions (such as deciding to not autoplay video).

Bug:  774219 , 721469 
Change-Id: I6c116ed344bb4f70f5e8116d559ec5519378eefd
Reviewed-on: https://chromium-review.googlesource.com/828146
Commit-Queue: Doug Arnett <dougarnett@chromium.org>
Reviewed-by: Scott Little <sclittle@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Cr-Commit-Position: refs/heads/master@{#527304}
[modify] https://crrev.com/db52c3fbcd47c7c02dfe36ef7bc5d8346e0f4a6c/content/renderer/render_frame_impl.cc
[modify] https://crrev.com/db52c3fbcd47c7c02dfe36ef7bc5d8346e0f4a6c/content/renderer/render_frame_impl.h
[modify] https://crrev.com/db52c3fbcd47c7c02dfe36ef7bc5d8346e0f4a6c/content/renderer/render_frame_impl_browsertest.cc
[modify] https://crrev.com/db52c3fbcd47c7c02dfe36ef7bc5d8346e0f4a6c/third_party/WebKit/Source/core/BUILD.gn
[modify] https://crrev.com/db52c3fbcd47c7c02dfe36ef7bc5d8346e0f4a6c/third_party/WebKit/Source/core/exported/LocalFrameClientImpl.cpp
[modify] https://crrev.com/db52c3fbcd47c7c02dfe36ef7bc5d8346e0f4a6c/third_party/WebKit/Source/core/exported/LocalFrameClientImpl.h
[modify] https://crrev.com/db52c3fbcd47c7c02dfe36ef7bc5d8346e0f4a6c/third_party/WebKit/Source/core/frame/LocalFrame.cpp
[modify] https://crrev.com/db52c3fbcd47c7c02dfe36ef7bc5d8346e0f4a6c/third_party/WebKit/Source/core/frame/LocalFrameClient.h
[add] https://crrev.com/db52c3fbcd47c7c02dfe36ef7bc5d8346e0f4a6c/third_party/WebKit/Source/core/frame/LocalFrameTest.cpp
[modify] https://crrev.com/db52c3fbcd47c7c02dfe36ef7bc5d8346e0f4a6c/third_party/WebKit/Source/core/loader/FrameFetchContext.cpp
[modify] https://crrev.com/db52c3fbcd47c7c02dfe36ef7bc5d8346e0f4a6c/third_party/WebKit/Source/core/loader/FrameFetchContextTest.cpp
[modify] https://crrev.com/db52c3fbcd47c7c02dfe36ef7bc5d8346e0f4a6c/third_party/WebKit/public/web/WebFrameClient.h

Some progress per comment 2: the PreviewsState bitmask is now available in LocalFrameClient::GetPreviewsStateForFrame()

So fundamentally the check for LoFi could active be something like:
   if (Client()->GetPreviewsStateForFrame() &
       (WebURLRequest::PreviewsState::kClientLoFiOn |
        WebURLRequest::PreviewsState::kServerLoFiOn)) {
      // Don't load video.
   }

Passing to Scott now to consider whether this logic should be encapsulated 
in a helper method somewhere.

Per Ben's original comment of this applying only to LoFi's as of Oct 2017, I deduce that autoplay should not be disabled for LitePage preview (as it is a
performance preview primarily vs. data savings?).

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

commit a7014eeba619d6f4b7a7f607451243ebaa1181b2
Author: Doug Arnett <dougarnett@chromium.org>
Date: Thu Feb 15 17:41:19 2018

Adds helper method to check if frame should be trying to save data

This is intended an api for video autoplay logic to check to decide not
to autoplay if a data saving preview is in effect for the frame.

Bug:  774219 
Change-Id: I143a7146b683d9e7ddcd953f52701f9abc17f6e7
Reviewed-on: https://chromium-review.googlesource.com/917322
Reviewed-by: Scott Little <sclittle@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Reviewed-by: Mounir Lamouri <mlamouri@chromium.org>
Commit-Queue: Doug Arnett <dougarnett@chromium.org>
Cr-Commit-Position: refs/heads/master@{#537061}
[modify] https://crrev.com/a7014eeba619d6f4b7a7f607451243ebaa1181b2/third_party/WebKit/Source/core/frame/LocalFrame.cpp
[modify] https://crrev.com/a7014eeba619d6f4b7a7f607451243ebaa1181b2/third_party/WebKit/Source/core/frame/LocalFrame.h
[modify] https://crrev.com/a7014eeba619d6f4b7a7f607451243ebaa1181b2/third_party/WebKit/Source/core/frame/LocalFrameTest.cpp

New LocalClient::IsUsingDataSavingPreview() api now landed.

Refreshed during triage, any updates? How's this going?

Refreshed during previews triage. Is this still targeting M-68?

Note this is independent of the autoplay behavior when Data Saver is enabled. Media should (ideally) never autoplay when a preview is shown.

Refreshed during triage.

Refreshed during triage.

Refreshed during triage. 

Refreshed during triage

This seems to be a P3 since the impact on data savings is unclear.

Reopen if you feel strongly.