Flash component updater is actually only enabled on beta/M57. This sounds more like a html5 by default.
https://blog.chromium.org/2016/12/roll-out-plan-for-html5-by-default.html

Anthony, do we have enterprise settings to influence the behavior?

I believe that they should be able set the DefaultPluginsSetting policy to 1 (Allow all sites to automatically run plugins).  That will disable HBD and always run Flash.

https://www.chromium.org/administrators/policy-list-3#DefaultPluginsSetting

The policy mentioned by #3 is not available while running kiosk mode since it is a user policy in Chrome OS.

+Toni, what would it take for kiosk mode to support this policy?

Hi,

The curious thing is that if you wipe one of the affected Chromebooks that has v56.0.2924.87, the issue is fixed and does not come back. I think that it's not related to the recent change to default to HTML5, since if it was, the issue should be present even after a full wipe.

I've tested in a Chromebook with v54, the app worked fine, then updated to v55, the app worked fine, and then at last to v56, and it worked fine. Please note that the device I tried with was recently wiped in v54 before updating it. I think that it may be related to devices that have been used for long without a wipe. I'll try to reproduce in a couple of devices that have not been wiped, hopefully I can reproduce and provide debug logs.

Please file feedback using Alt + Shift + i and put some unique string into the text field so we have an easier time finding it.
https://support.google.com/chromebook/answer/2982029?hl=en

feedback has been submitted. Used string "feedback  crbug.com/693739 ".

Let us know if you guys need anything else.

Thanks.

Hi,

I did test in a Dell Chromebook 11 (WOLF C6A-M2O-Q3L), it had v55.0.2883.105 (8872.76.0) Stable. I set the Kiosk app in the Admin Console, rebooted, and it failed to display the flash content with the same error message as the one in the issue description. With this test, we can say that it's not related to the update from v55 to v56. After the test I wiped the device and the content was displayed correctly, then updated to 56.0.2924.87, and it displayed correctly as well.

Logs from my test device in the Drive folder at https://drive.google.com/open?id=0Bxg-rTzA58PeUktNMG9ITGhlemc (Google restricted)

Please note that I captured the logs eright after each attempt, the timestamp is in the log name. Details below:

>> v55 debug-logs_20170220-094150 - not working. Attempted on Feb 20th, 09:41 CST
>> v55 debug-logs_20170220-095856 - working after a wipe - Attempted on Feb 20th, 09:58 CST
>> v56 debug-logs_20170220-100610 - working after updating -  Attempted on Feb 20th, 10:06 CST

All logs were gathered from the same device.

Link for #8: http://feedback/#/Report/53666835926

1. Flash is on the system.
2. Two ppapi processes get launched (07:44:25 and 07:44:38)
3. At least one of which reports ('SANDBOXED') as being Flash (between 07:44:25 and 07:44:52).
4. One ppapi process suspiciously dies. Not sure if it was Flash. (07:45:08)
5. One ppapi process is alive. Not sure if it is Flash.

[1102:4084:0220/074425.998090:ERROR:get_updates_processor.cc(244)] PostClientToServerMessage() failed during GetUpdates
[WARNING:flash/platform/pepper/pep_module.cpp(63)] SANDBOXED
[1102:1612:0220/074452.138853:ERROR:device_status_collector.cc(114)] Unable to get volume status for /special/arc-content

[1102:1593:0220/074425.881818:VERBOSE2:ppapi_plugin_process_host.cc(468)] ppapi plugin process launched.
[1102:1593:0220/074438.896789:VERBOSE2:ppapi_plugin_process_host.cc(468)] ppapi plugin process launched.
[1102:1593:0220/074508.822877:VERBOSE1:ppapi_plugin_process_host.cc(504)] PpapiPluginProcessHost[broker]<IPv6: 1>OnChannelError()

chronos   4591  0.0  0.6 405440 26908 ?        Sl   07:44   0:05 /opt/google/chrome/chrome --type=ppapi [...]

There is unfortunately nothing insightful I found in the logs from #9.

[Context for why the behavior maybe inconsistent on M56]

HBD rollout is being controlled by a Finch experiment (we're currently deployed to 50% of the users).

A wipe of the device would likely reset the Finch configurations, resulting in a re-roll of the devices, having the probability of not enabling the feature.

We'll be at 100% next week, so it's unlikely that re-flashing the devices will continue to provide a viable fix.

Setting user policy won't work for kiosk apps (user policy does not get applied).

Any policy workaround would have to be done using device policy.
Given that the feature can be controlled by a flag, this can be achieved using start_up_flags policy - it should be set to:
["--disable-features=PreferHtmlOverPlugins"]

(the policy seems to be a string list, each list entry corresponding to a startup flag)

I am using Acer Chromeboxes.  They all have the following version of the ChromeOS 56.0.2924.87.  I have wiped the devices that show the issue, but a few days later the devices I wiped, show the same exact issue.

Are we OK with scaling up the feature deployment, given that it breaks flash content in kiosk apps?

It seems to me that we should handle this issue better than requiring a flag to be set (i.e. PreferHtmlOverPlugins should be disabled for kiosk apps by default, e.g. by always treating user engagement for platform apps over the treshhold for allowing flash content).

Actually, I assume this would affect other platform apps as well (not just ones running in kiosk). 

Talking with Raj, it looks like we want flash content to run by default in kiosk applications.

What would it take to enable flash kiosk apps by default always?

"Always" is, like, a big thing - as the web is going html5 by default. Or as Mr. Gorbachev used to say: "He who comes too late is punished by life".

Ideal solution would be to have a policy to allow disabled/outdated plugins to run in Kiosk mode. I believe this is the policy - https://www.chromium.org/administrators/policy-list-3#AllowOutdatedPlugins

Looks like it is a user-policy. We will be able to enforce a user-policy in Kiosk mode (once for each configured kiosk app).

Can you confirm that AllowOutdatedPlugins will enable flash without user intervention?

it can be done via device policy - see comment #14,

But what worries me is that, when running the app in question in kiosk, clicking "Install Adobe Flash" does not actually enable flash - so, it the policy is not set, the app content cannot actually be shown.

Adding device start-up flag policy to append start-up values for chrome may not be the ideal solution (as opposed to having a specific policy) because - 

* Chrome process may restart when starting a kiosk session (especially when passing flags). Though we added a fix in M56 so that Chrome will not restart for auto-launched kiosks. The original purpose for that policy was to send start-up flags for the sign-in screen

* Relying on a flag may not be a good idea either

Every path forward on this seems bad.  We definitely don't want to encourage Flash usage, but we also definitely don't want to have business critical kiosks breaking on our users.

zelidrag@ over to you. We really need to figure out our plans WRT Flash in kiosk.  Let's chat in person.

sduraisamy@ anything that involves Flash isn't going to be ideal and will get less ideal over time.

I am a teacher who has created a kiosk app for our primary students to access their online programs that run Flash.  This makes online access available to our 5 year olds.   We also use MAP kiosk app that had been running FLASH and I noticed today that their kiosk app was working.  What did they do to make that work?  Did they rewrite their code into HTML5?  
As I am reading these comments I am wondering also if it could be possible to allow Flash to run on kiosk apps and have that be another checkbox to check in the admin console?  
Also am I to try other ways to make it work or will hopefully Google make some changes so this magically corrects?  

Waiting for an update so our kiddos can get back to work.

Re #23:

Is this the MAP in your question?
https://chrome.google.com/webstore/detail/map-chromebook-testing-ap/omkghcboodpimaoimdkmigofhjcpmpeb/support?hl=en

The old 2013 FAQ mentions Flash requirements
https://www.nwea.org/content/uploads/2013/04/Common%20Core%20MAP%20FAQ_July2013_0.pdf

The new one from February 2017 does not
https://teach.mapnwea.org/impl/PGM2_System_Technology_Guide.pdf

I don't have an account, but did not see Flash used in the intro video. So maybe they switched.

Have you tried in your kiosk setting to use the flag as discussed above?
--disable-features=PreferHtmlOverPlugins

Re #23:

I didn't try the flag since I am so new to this I wasn't really sure where to do it.  Do I do it within my app or do I do it with in the Admin Console?

Guys, kiosks support user policies. All that's needed is for cpanel to pass down the appropriate flag in the kiosk session's user policy bundle. AFAIK no client change would be required.

It's been 4 days since the last post. Any movement or work around on this? I have have 3000 devices this is effecting for students. 

We have over 17,000 devices in our domain.  1000, at least, are effected by this as well.

Hi team,

Is there any chance that we can increase the priority to this issue?. It's impacting a lot of users and devices at the time.

Thanks!

Hi Google team,

I have the same concerns as others in this thread.  I manage the technical support team for a large Saas education company and our end users are running into this "Flash update" issue in Kiosk mode and with Public sessions on their Chromebooks.  Can you allow the admin console to control this ? Or do you have a viable workaround that we can share with our customers ?  This is impacting hundreds of thousands of user sessions a day (young kids in school).
Can we escalate the priority at Google ? I am happy to the Google tech team directly if that will help. 
Thank you

Let's add following command line switch to the policy for all kiosks devices (including public session), regardless of kiosk app auto-launch status:

--disable-features=PreferHtmlOverPlugins

acknowledged by server team

Does this mean we have an ETA for a fix now that it is a priority 0?

Hi, I'll bounce this back to you guys once I disable the feature on ChromeOS via Finch.

My intuition is to just turn this off for ChromeOS Stable, and leave ChromeOS Beta, Canary, and Dev to stay the course.

Any objections?

Patch turning it off for ChromeOS Stable just landed. Can anyone verify? Should require a restart.

cl/148940135

Can we please turn this off on Beta too - customers are also testing on beta channel.

vidster: I wanted to keep Beta/Canary/Dev on, since they would be the early warning that something bad was going to happen soon.

If we turn HBD off for Beta also, we lose that early warning. Thoughts?

Tommy, thanks. But I feel it really should only be disabled in an enterprise setting/kiosk. Normal Chrome OS users should not be treated differently from Windows/Mac/Linux.

Also, I agree HBD should stay enabled on Beta.

ihf: AFAIK, skare is working on the feature to allow disabling on Kiosk only. I agree setting all of ChromeOS Stable to 0% was unfortunate.

Regarding the medium term solution -- is disabling this feature for kiosk mode only feasible based on the suggestion in https://bugs.chromium.org/p/chromium/issues/detail?id=693739#c31 ?

Checked that Flash works by default on Stable devices. 
Tested this on M56( 9000.91.0:56.0.2924.110). 
Tested this in Kiosk mode with the app (helpfully) provided by OP(ie, Lexia Reading Core5 version 3).
Thank You tommycli@ for turning the finch flag off for ChromeOS Stable.

Will this change have a similar affect on those running chromebooks in Public Sessions (and not explicitly Kiosk)?  Based on the ChromeOS comment it seems plausible but would like confirmation.  Thanks

Will this resolve the flash issue in a public session as well?

Yes. It should work for Public-session and user-mode. It requires system restart.

Thanks Krishna for testing and confirming.
Thanks Zel, Tommy, Ryan and team for jumping on this!

Thank you! This could be an incredible help for our customers.

As a note it will be helpful to collate responses from customers/schools/developers/partners on the Flash based apps you will continue to be using in your environments in Kiosk Mode and in Public Sessions. Please feel free to comment here.

vidster: Yes, and I wonder if we should exempt Flash within Chrome Apps.

+ericde who may have thoughts.

+groby who may have thoughts also.

Our product is i-ready.com. It is used in both kiosk mode and public session mode by our students and teachers.  

Also, if the chromium team is open to it we would be very willing (and grateful) to collaborate on your plans to re-implement a version of this in the future as it is understood that a long-term ChromeOS exclusion is not your desired state.

To echo vidster@'s request.  Having a good sense of impacted Flash content would be exceptionally valuable to the Chrome team, as we make decisions about the roadmap for Flash Player and weigh all the potential implications of continuing support (security, performance, stability, user impact, content, etc.).

With that said, I would strongly encourage all Flash developers to be actively exploring HTML5 alternatives, as future roadmaps are likely to be increasingly more limiting.

I believe many of the companies and/or educators who spoke up on this bug are in a similar situation to the company I represent.  We have thousands of hours of K-12 instructional content that we are aggressively replacing (a major portion was moved to HTML5 in December) but the process takes time.  It is not a simple conversion.  

In the meantime the popularity of Chromebooks in schools has made them very prevalent.  We have over 1 million US schoolchildren using them daily for our mixture of Flash and HTML.  Happy to share more details in PM.   

We are a school district in CT with 4,000 Chromebooks deployed.  We use the Pubic Session mode for our younger kids with Clever Badges.  It is IMPERATIVE that flash content remain due to the overwhelming FLASH content we use with our users.  If you would like a list of the apps that require flash , I'd be happy to help.

Just to confirm with everyone else - Our 3000 CB effect by this issue have been fixed with a reboot. Thanks everyone for there hard work.

Is there going to be a point where this is going to be turned off for good? Is there a hard date? 

Can you confirm that the flag is also off for kiosk&public session for M55? We've frozen our 1500+ chromeOS devices at M55 due to testing client requirements (they don't support M56 and we're not taking the chance of problems).

The change in #38 was for M55 and up.

School District here with 9000 Chromebooks.  I tested the patch here with several different models of Chromebooks and can confirm that the patch fixed our issue with iReady login window in Kiosk mode.  I am waiting to get confirmation from our sites that it is working again for them.

I have spoken with a couple of our software vendors that still use Flash and tried to get them to understand that they need to move to HTML5, and the typical answer is "we are working on it" with no ETA...

Is the Finch experiment referred to by Anthony applicable to all devices (not just Chromebooks)?  Also, what is the new date for 100%?

Temporary changes were made for all Chromebooks on M55+ to revert to M54- behavior with regards to running Flash. The longer term fix will be to target only Enterprise Chromebooks, especially kiosk mode, to support legacy Flash override (undetermined support duration). M56 Win/Mac/Linux remain at 100% html5 by default (HBD) and are in no way impacted by the Chromebook change. Non Enterprise/Kiosk Chromebooks (normal users outside of schools) are expected to conform to standard Win/Mac/Linux Chrome behavior soon again.

Thank you, so non Chromebook M56 use cases are already at 100 percent, correct?  Can you kindly confirm when they went to 100? The roadmap document I've seen just stated "February".

In what forum will the changes for Chromebooks in schools be discussed and communicated?  How can the interested parties in the bug be made aware and provide input?  Thanks.

Pri-0 bugs are critical regressions or serious emergencies, and this bug has not been updated in three days. Could you please provide an update, or adjust the priority to a more appropriate level if applicable?

If a fix is in active development, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

The emergency Finch config change has been released. We're still working on a long term fix -- though it might be from Finch team instead of HBD team.

Our machines have been working fine for a few days but today they are getting the adobe error again.  Are there any updates on this issue?

re: comment71, are you running Beta version of ChromeOS?

I am still quite interested in understanding what voice those impacted by this bug will have in the revised strategy to re-implement it.  At the least, where and how will we be notified by the new strategy in terms of implementation and timeline? Thanks and please advise.

No we are not running a beta version

Could you please report the output in about:chrome lines "Google Chrome:", "Platform:" and "Flash:".

dropping priority as the finch change seems to have resolved this for most customers.

Is this still an issue, or can we retire this bug ? We are on 58 now.

We still need to re-enable the HTML5 by Default feature on Chrome OS, once there is console support to disable it for kiosk mode/ public sessions.

To set a timeline, we are going to pull the finch config for Chrome OS when Chrome 60 goes live (Aug 1st).

In Chrome 60, will there be an option to enable Flash for a Kiosk App?

+Raj - Who is probably in the best position to answer about the timing of upcoming cPanel changes.

Yes. We will be offering a control at the app-level (per kiosk apps) to enable Flash.

Just to clarify, when Chrome 60 goes live, all Chrome OS versions 55 and up will have HBD turned back on, correct?

Yes. All the kiosk apps will have a setting turned-on by default that will enable Flash in kiosk mode. As an Admin, you should be able to turn flash off as required.

That's the plan, yes.

Updating labels to match comments #84/#85

Kiosk mode now has a way for the Admins to enable/disable flash. It is already added to the admin console and available to all admins.

It should not be release-stable. We can have this bug open for a few weeks to make sure flash is working as expected on Kiosk mode / enterprise devices and then should close this one.

When was it pushed out ?

It was pushed out on July 24.

Closing. Please open a new bug if the resolutions pointed out in c#82+ are not working properly.

Verified no issue on M64.0.3282.190 10176.76.0 stable glimmer with app showing Flash content in Kiosk mode.