Checking further, this seems to be true for Flash videos on all sites.

The video isn't on that home page any more.  The permalink is http://pluto.jhuapl.edu/News-Center/News-Article.php?page=20160714-2.  But again, it doesn't really matter.  You can see this on any Flash video.

More significantly, as of 55.0.2845.0 the failure mode has changed.  Now instead of saying "Right-click to play Adobe Flash Player", and failing when you play it, it says "download failed" immediately when the page loads.

Back to the original failure mode in 55.0.2846.4.

Sorry if some of these are obvious, but I just want to get all the information in one place:

 * Can you tell me the version and location of Flash in chrome://plugins? (Click +Details to see the location.)
 * Do you get the content if you click "Run all plugins this time" from the omnibox prompt?
 * Do you get the content if you re-open the same page in a new tab after you see the white box?
 * Do you get the content if you turn off control-click-to-play ("ask to run plugins")?¹
 * Do you get the content after you restart Chrome?

¹If you are on a corp machine, you will have to delete your group policy settings to be able to do this. Or, you can try on a non-Google machine.

Can you tell me the version and location of Flash in chrome://plugins? (Click +Details to see the location.)

    23.0.0.162
    C:\Users\dbloch\AppData\Local\Google\Chrome SxS\User Data\PepperFlash\23.0.0.162\pepflashplayer.dll

Do you get the content if you click "Run all plugins this time" from the omnibox prompt?
Do you get the content if you re-open the same page in a new tab after you see the white box?
Do you get the content after you restart Chrome?

    No, same result.
    Note that this has persisted through half a dozen upgrades.
    
Do you get the content if you turn off control-click-to-play ("ask to run plugins")?

   I didn't know I could do this.  How do I delete my group policy?

Also note, I have a dev channel instance running on the same machine which I've been careful not to restart for the last two weeks, and Flash still runs there.  It's running Chrome 54.0.2837.0, and, interestingly, a different major revision of Flash, 22.0.0.209.

> How do I delete my group policy?
On Windows: run regedit; delete keys (and all subkeys): HKLM/Software/Policies/Google/Chrome and HKCU/Software/Policies/Google/Chrome
On Linux: sudo rm /etc/opt/chrome/policies/managed/*

It seems like I can repro this on Linux (trunk build @ dabd7e3dbb95b56baa338202061730cb2a03241f) if and only if the "Let me choose when to run plugin content" is enforced by group policy. If I disable the group policies, content loads. If I then manually choose that setting via chrome://settings, content continues to load well.

Apparently I don't have enough access to do this (on corp Windows machine).  Deleting the key fails with "Error while deleting key" and no information.

OK. Based on my own tests, I can repro consistently on Windows and Linux when under corp policy, but not when manually choosing that setting. I'll be out for a week, assigning this to wfh@ to take a look at (or delegate).

I've tested on Windows and regardless of policy (even if Flash is autorunning, with no policy settings) videos don't play.

I suspect that 23.0.0.164 is just a bogus version of Flash and it should be rolled back.

Assigning to dimu.

Setting myself as a temporary (placeholder) owner.

The version of Flash Player should be ok.  Let's start by getting a bisect on this, to see where it regressed.  It looks like it only appears when DefaultPluginsSetting is set to 3 by enterprise policy.

(Also worth noting that http://www.adobe.com/software/flash/about/ is broken at the moment, so maybe find some other Flashy site to test on for the bisect.)

re: 13 I tried with no policy set and could still not play video. I could load other Flash sites, but the NASA one never worked. Flash loaded automatically each time (no click to play).

I can try again tomorrow to double check.

I confirmed the same behavior using the Akamai video test which was previously working

http://wwwns.akamai.com/hdnetwork/demo/flash/default.html

This works fine in Flash 22.0.0.209 and doesn't load in 23.0.0.162.

As a final test, I copied the DLL from 22.0.0.209 over the 23.0.0.162 DLL and then Flash loads fine. There is definitely something bad with 23.0.0.162.

ah now I noticed that Flash is 23.0.0.164. This does not load the first time but upon a refresh of the page, it loads successfully.

Unable to get bad builds during python tool bisect, so providing manual bisect information below.

Bisect Information:
=====================
Good build: 54.0.2836.0 Flash version (23.0.0.141)
Bad Build : 53.0.2785.0 Flash version (Disabled)

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/54.0.2836.0..54.0.2838.0?pretty=fuller&n=10000

From the above change log suspecting below change

Review URL: https://codereview.chromium.org/2273443002

sorin@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Thanks!

Would it be possible to download the ppapi Flash Player bundle from https://get.adobe.com/flashplayer/ and do a bisect on Chromium builds.  Looking at the change logs there are ~10-20 changes affecting plugins, happening in the span of 2836 and 2838.

I'm pretty sure that Sorin's CL isn't the culprit here, since it affects the component updater installation path and not explicitly the plugin loading.

I only have ideas how Flash unbundling works but I will try to explain the scope of my change.

My code is affecting whether Flash and other binary components are considered for component updates, when the group policy ComponentUpdatesEnabled is set. When that happens the update checks for Flash include an updatedisabled="true" attribute, which is a hint for the Omaha server to not return an update for Flash. There is defensive coding further on the execution path to prevent installing an update, had the server returned one anyway.

If there is no Flash bundled in the test scenario being discussed, and the group policy is set, then this change will prevent Flash from being retrieved on-demand from Omaha. This could also happen if my code is buggy and blocks updates regardless of group policy.

To rule out my change, I'd like to see what chrome://components shows for Adobe Flash, and if triggering a manual on-demand update for Flash retrieves the component or not.

Otherwise, my changes do not affect the load path of components, but the same underlying code
is used by both installers and the update code, and one needs to look at details.

I am in investigating broken pnacl component updates in M53, please ping me if this issue needs to be escalated or it can wait a few days.

Re bisected the issue again on Mac 10.11.6 and got all good builds only.

Narrow Bisect::
==================
54.0.2837.0 --   413618    (Flash 23.0.0.141)
54.0.2838.0  --   413929   (Flash 23.0.0.151)

Unable to do the bisect using chromium builds as not able to find the good(413618) and bad(413929) revisions on chromium builds URL 
http://commondatastorage.googleapis.com/chromium-browser-continuous/index.html?prefix=Mac/
Last updated revision was 381909.

Could any one from dev team please look into this issue.

Thanks,

Adding MTV Team if they can help in providing the bisect for this issue.

Thanks,

Doing some local testing, the issue appears to be related to how the DefaultPluginSetting for BLOCKING (3) gets handled.

If we remove the user policy setting that value, the plugin has no issue loading, even when we have click to play enforced.  

Here's a demo video, walking through all four settings (BLOCKING -3, Run all ..., Detect ..., and Let me choose ...).  The video unfortunately is over the 10MB cap, but it shows the issue pretty well and it's easy to repro the good and bad behavior w/ regedit.

https://drive.google.com/a/chromium.org/file/d/0B4BzywBY8-FtS1pXRUZuV1UyUG8/view?usp=sharing

Note: If you change the policy in regedit, please be sure to refresh your policy settings in chrome://policy so that the new settings take effect.

waffles is ooo at the moment. can someone clarify if this bug needs immediate attention from someone in the meantime?

Unfortunately this issue impacts all Googlers running Canary, Dev, and Beta, (and perhaps Stable - need to verify) so we are seeing a lot of internal reports of Flash breakage (taking different forms), and it's also having implications on testing.  Effectively it's a side effect of using component updates.

The other issue here is that with M54+ being a component only release, we have a narrow window to get a patch on trunk and on to the release branch before it affects all Googlers.

If it's possible to prioritize sooner, that would be ideal.  Help would be greatly appreciated :).

Need TE to confirm, but the issue doesn't seem to impact either 53 or 54 (on Windows).

Sorry, I take that back.  The Pluto example is broken on 54, "about Flash" is only broken on 55.

Can reproduce without Policy.

Linux Tip of Tree with manually setting Content Settings to "Let me choose".

Flash binary is the src-internal one: /mnt/src/chromium/src/third_party/adobe/flash/binaries/ppapi/linux_x64/libpepflashplayer.so

23.0.0.162

Can reproduce without Policy using google-chrome-unstable package with component-updated Flash also.

Flash: 23.0.0.166
Chrome: 55.0.2853.0

Please find the bisect range where this is broken :
https://chromium.googlesource.com/chromium/src/+log/54.0.2837.0..54.0.2838.0?pretty=fuller&n=10000

The two changes in there that might be candidates are HBD work (refs/heads/master@{#413842}) and component updater work (refs/heads/master@{#413623})

pbommana@ - can you run a per-revision bisect to pinpoint which one of the two it is? 

We tried bisecting w/ Chromium builds, however by design (basically we don't want to serve components to fork of Chromium) the component updater is disabled for "unofficial" builds.

Just taking a quick look, the component updater CL appears to be changing the way that the client communicates with Omaha and persists a certain piece of data (i.e. applying a cohort to a client, as a means of partition populations, and communicating it back to the server).  The code is a somewhat generic, at the level of Omaha protocol/ persistence, and doesn't look like it would affect plugin loading.

One important observation, while we were doing the bisects.  As part of the validation, we triggered the component update (and validated the presence of the component) prior to loading any content on the Pluto url.  My suspicion would be that the component update path was likely out of the way by the time the video attempted to load. 

Doesn't the new bisect use official builds? (There was just an e-mail going around, look on chrome-team for "Per Revision Manual Bisects Happening!")

Anyways, skimming the HBD CL, it looks like everything there is guarded behind a feature flag, so it's not a likely candidate either. 

We'll need to somehow bisect by revision :(

Agree: I looked at the revs in the bisect, there's too many: I don't have a good theory as to what's going on.

Since there's so many things in flux for Flash: (component updater changes, Flash on-demand, PPS tiny, HBD) - a per rev. bisect would be really really helpful :)

Though: I think we should take wfh@'s observation that copying over the Flash 22 binary over the Flash 23 plugin fixes it seriously. Maybe the culprit is Flash 23's interaction with Chrome.

We were able to reproduce this issue w/ component updates of both 22.0.0.209 and 23.0.0.166(162).  It wasn't specific to the new Flash build.

please find the bisect range and cc'ed japhet@ :
You are probably looking for a change made after 413906 (known good), but no lat
er than 413907 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/3bd5a3238b915071532c92c9d6f63cc844a66be9..8489f1bf78c2c6f296e0df6c529751d29e8a0188

I don't have time to dig into this right now, but:

Before this change, WebViewPlugin had two different didReceiveResponse APIs, overriding :
  void WebViewPlugin::didReceiveResponse(unsigned identifier,
                                         const WebURLResponse& response)
  void WebViewPlugin::didReceiveResponse(const WebURLResponse& response)


The first one overrides WebFrameClient, the second WebPlugin. With the rename in the CL, there's only one didReveiveResponse function. Which, IIUC, is now shared between WepPlugin and WebFrameClient.

Which makes me wonder if WebViewPlugin::ReplayReceivedData still gets the right WebResponse - we used to store the response into |response_| in the WebPlugin::didReceiveResponse and then forward it in ReplayReceivedData. The new code gets the response from web_frame_->dataSource() - is that really the same WebResponse?

 Issue 646307  has been merged into this issue.

 Issue 644756  has been merged into this issue.

I also can repro this at will. Reverting 8489f1b fixes the issue; japhet@ has an idea about how this can be fixed short of reverting; reassigning.

Issue 647749 has been merged into this issue.

Adding reference to WIP CL, so I can stop searching for it on codereview.chromium.org.

https://codereview.chromium.org/2349443003/

Making this issue public.

Removing RVG

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

commit 8ed4bf69eca5e2696aeab731a8e9a15e8f379f2b
Author: japhet <japhet@chromium.org>
Date: Sat Sep 17 22:24:36 2016

Listen to didReceiveResponse() to get the response in WebViewPlugin.

This is a partial revert of the WebViewPlugin changes in
https://crrev.com/8489f1bf78c2c6f296e0df6c529751d29e8a0188

BUG= 641028 

Review-Url: https://codereview.chromium.org/2349443003
Cr-Commit-Position: refs/heads/master@{#419387}

[modify] https://crrev.com/8ed4bf69eca5e2696aeab731a8e9a15e8f379f2b/components/plugins/renderer/webview_plugin.cc
[modify] https://crrev.com/8ed4bf69eca5e2696aeab731a8e9a15e8f379f2b/components/plugins/renderer/webview_plugin.h

Verified the fix on today's Canary, requesting merge to 54.

Your change meets the bar and is auto-approved for M54 (branch: 2840)

Issue 648269 has been merged into this issue.

Issue 648235 has been merged into this issue.

Users experienced this crash on the following builds:

Mac Dev 55.0.2859.0 -  0.27 CPM, 3 reports, 3 clients (signature WebViewPlugin::ReplayReceivedData)

If this update was incorrect, please add "Fracas-Wrong" label to prevent future updates.

- Go/Fracas

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

commit 554d5bd354d04ad9ccdea34947164db3302f11c9
Author: Nate Chapin <japhet@chromium.org>
Date: Mon Sep 19 16:40:08 2016

Listen to didReceiveResponse() to get the response in WebViewPlugin.

This is a partial revert of the WebViewPlugin changes in
https://crrev.com/8489f1bf78c2c6f296e0df6c529751d29e8a0188

BUG= 641028 

Review-Url: https://codereview.chromium.org/2349443003
Cr-Commit-Position: refs/heads/master@{#419387}
(cherry picked from commit 8ed4bf69eca5e2696aeab731a8e9a15e8f379f2b)

Review URL: https://codereview.chromium.org/2352673003 .

Cr-Commit-Position: refs/branch-heads/2840@{#412}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/554d5bd354d04ad9ccdea34947164db3302f11c9/components/plugins/renderer/webview_plugin.cc
[modify] https://crrev.com/554d5bd354d04ad9ccdea34947164db3302f11c9/components/plugins/renderer/webview_plugin.h

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

commit 554d5bd354d04ad9ccdea34947164db3302f11c9
Author: Nate Chapin <japhet@chromium.org>
Date: Mon Sep 19 16:40:08 2016

Listen to didReceiveResponse() to get the response in WebViewPlugin.

This is a partial revert of the WebViewPlugin changes in
https://crrev.com/8489f1bf78c2c6f296e0df6c529751d29e8a0188

BUG= 641028 

Review-Url: https://codereview.chromium.org/2349443003
Cr-Commit-Position: refs/heads/master@{#419387}
(cherry picked from commit 8ed4bf69eca5e2696aeab731a8e9a15e8f379f2b)

Review URL: https://codereview.chromium.org/2352673003 .

Cr-Commit-Position: refs/branch-heads/2840@{#412}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/554d5bd354d04ad9ccdea34947164db3302f11c9/components/plugins/renderer/webview_plugin.cc
[modify] https://crrev.com/554d5bd354d04ad9ccdea34947164db3302f11c9/components/plugins/renderer/webview_plugin.h

Looks like this change broke PluginPlaceholder/BlockedPlugin functionality. To reproduce the problem:
1. Start chrome with command-line switch "--override-plugin-power-saver-for-testing=always"
2. Open some office document, e.g. http://www.williamspublishing.com/PDF/5-8459-0793-4/part.pdf
Expected:
  PDF is loaded with "Play" triangle overlay.
Actual result:
  Whole page is black.

Command-line switch "--override-plugin-power-saver-for-testing=always" switches execution in ChromeContentRendererClient::CreatePlugin to ChromePluginPlaceholder::CreateBlockedPlugin branch instead of immediate plugin creation.

Besides that NOTREACHED() check in WebViewPlugin::didReceiveResponse (8e1badd5fbc054cf4ffc9303e8cb0aa22ce55ca6) seems to be unjustified, as this call happens when ChromePluginPlaceholder is used:
  browser.dll!WebViewPlugin::didReceiveResponse(const blink::WebURLResponse & response) 
  blink_web.dll!blink::WebPluginContainerImpl::didReceiveResponse(const blink::ResourceResponse & response)
  blink_core.dll!blink::PluginDocumentParser::createDocumentStructure() 
  blink_core.dll!blink::PluginDocumentParser::appendBytes(const char * data, unsigned int length) 
  

Deleted: Screencast 2016-12-02.mp4 803 KB

	Screencast 2016-12-02.mp4 803 KB View Download