Unable to reproduce the issue on Stable build 61.0.3163.100 and canary 63.0.3230.0 on Windows 10, Mac 10.12.6, Ubuntu 14.04. Hitting the Play button twice played the video inside iframe without any issues. Screen shot attached.

Request you to please check and please let us know if we missed any thing else here.

Thanks.!

Deleted: Flash.png 144 KB

	Flash.png 144 KB View Download

is "--top-document-isolation" flag enabled?

 

Deleted: Top_document_isolation_flag.jpg 41.6 KB

	Top_document_isolation_flag.jpg 41.6 KB View Download

Thank you for providing more feedback. Adding requester "ranjitkan@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

Able to reproduce the issue in windows 10 , mac os 10.12.6 and ubuntu 14.04 using chrome M61 #61.0.3163.100 and M63 #63.0.3236.0 after enabling the flag given in comment #3 . If flag is not abled issue is not reproduced.

This issue is seen from M55 and earlier to M55 , the given flag is not available in chrome://flags and is a Non-regression issue.

Marking it as untraiged for further inpust on this.

Thanks!

Ken, would you be able to check whether this affects other OOPIF modes and not just TDI?  Since the video plays but doesn't render, I wonder if there's something regressed in Flash visibility inside OOPIFs.  I believe Flash used to play fine from OOPIFs at some point, but it's been a while since I've tried that.

Might be related to  issue 593520 , but for nested iframes?

On Windows I can repro the problem with TDI, but I haven't been able to make it occur with --site-per-process.

So far I haven't been able to figure out why that might be, but I'm still investigating.

hi, 
this may help you:

it's look like the sub_frame is observing to the right renderWidget

i was able to fix it by this workaround code:

at render_frame_impl.cc:
void RenderFrameImpl::DidCommitAndDrawCompositorFrame() {
#if BUILDFLAG(ENABLE_PLUGINS)
  // Notify all instances that we painted.  The same caveats apply as for
  // ViewFlushedPaint regarding instances closing themselves, so we take
  // similar precautions.
  PepperPluginSet plugins = active_pepper_instances_;
  for (auto* plugin : plugins) {
    if (active_pepper_instances_.find(plugin) != active_pepper_instances_.end())
      plugin->ViewInitiatedPaint();
  }

  // fix oopfis rendering flash inside iframe  <----------------   
  if (render_view_ && !is_main_frame_) {
    render_view_->DidCommitAndDrawCompositorFrame();
  }
#endif
}

and at render_widget.cc:


void RenderWidget::DidCommitAndDrawCompositorFrame() {
  // NOTE: Tests may break if this event is renamed or moved. See
  // tab_capture_performancetest.cc.
  TRACE_EVENT0("gpu", "RenderWidget::DidCommitAndDrawCompositorFrame");
 
  // changes : OOPIS flash fix
  if (did_commit_and_draw_compositor_frame_)
    return;
  
  // prevent recursive calls 
  base::AutoReset<bool> draw_compositor_frame(&did_commit_and_draw_compositor_frame_, true);
  // end OOPIS flash fix

  for (auto& observer : render_frames_)
    observer.DidCommitAndDrawCompositorFrame();

  // Notify subclasses that we initiated the paint operation.
  DidInitiatePaint();
}

hope it helps

Thanks, that is helpful. I worked out that the problem is when the Flash video is loaded within a local frame that is within an OOPIF, which is why the sample you provided repros under TDI but not --site-per-process.

Indeed, it looks like the problem is that the child RenderFrame isn't registering itself with the correct RenderWidget, and so it doesn't get the DidCommitAndDrawCompositorFrame() message. I can put up a fix to make it register itself properly tomorrow, although I am surprised that this hasn't caused worse bugs.

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

commit c398e285eea601718751f6b6cac5a126bebba724
Author: Ken Buchanan <kenrb@chromium.org>
Date: Wed Nov 29 19:28:57 2017

Correctly register RenderFrames with their associated RenderWidgets

Currently all RenderFrameImpls call RegisterRenderFrame on the
RenderView, and additionally, out-of-process iframe RFIs call it on the
RenderWidgets that they own.

This is incorrect for local child frames of OOPIFs, because they need
to register with the OOPIF's RenderWidget also.

This patch corrects and simplifies RenderFrameImpl widget registration,
making all of them register with their associated widgets after their
WebFrame is created, and unregister just before their WebFrame is
destroyed.

Bug:  770622 
Change-Id: I51be01147d3a810bf6e6c0214150b3714ea1c181
Reviewed-on: https://chromium-review.googlesource.com/791071
Commit-Queue: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/master@{#520196}
[modify] https://crrev.com/c398e285eea601718751f6b6cac5a126bebba724/content/renderer/render_frame_impl.cc
[modify] https://crrev.com/c398e285eea601718751f6b6cac5a126bebba724/content/renderer/render_frame_impl.h
[modify] https://crrev.com/c398e285eea601718751f6b6cac5a126bebba724/content/renderer/render_frame_impl_browsertest.cc

This looks fixed on Canary.