I've got a problem with flash on some sites.
I've got a Chromebook that updated last week and since then I have problems with flash content on some websites.
My current chromeos is 9901.46.0, the chrome version is 62.0.3202.55 and the adobe flash version is 22.214.171.124. When I go to chrome://components the adobe flash player is up-to-date.
When I try to access some websites, I get the enable flash notification message but even if I add the website to the allowed websites (in Advanced settings), I still cannot access the content. I tried using the website on another chromebook, running chrome version 61.x and it is working fine. How can I resolve this problem?
Edit: I forgot to mention that I tried these - Use or fix Flash audio & video - Computer - Google Chrome
and they didn't work.
Chrome is making it more difficult to use Flash Player, and each Chrome update lately has included changes that make it more and more difficult.
While you should be able to activate Flash Player manually on those pages, the content may be written in such a way that Chrome doesn't provide the opportunity to run plug-in content.
If you can provide links to pages that don't work, we'd be happy to take a look, and share that information with the Chrome team.
I work on a website that still uses a lot of Flash and some of our customers are complaining about this. It only seems to affect some people with this version of Chrome. We have so far failed to reproduce it in the office but we have several customer support emails and screenshots.
You mention above that "the content may be written in such a way that Chrome doesn't provide the opportunity to run plug-in content". Could you elaborate? Is there anything we can change at our end?
Each major browser has implemented their approach to Click-To-Play a little differently, and each monthly update in those browsers may or may not introduce new changes that push that agenda forward. With Chrome, the penultimate goal is to require end-users that need to use Flash Player to launch Chrome with optional commandline flags, before support is dropped entirely.
In the interim, you can probably do some things to tune your content, but if your organization isn't already executing against a concrete migration strategy at this point, you should probably get started. Your user experience is going to get significantly worse, well before 2020.  
All of that context was primarily given to say that you're going to need to experiment on a solution, and you're going to need to start tracking upcoming browser changes, in order to stay ahead of the new limitations aimed at plug-ins.
If you want to model something, the Zynga folks working on Farmville 2 have a really good experience that detects and guides users through the various possible failure states.
Firefox actually seems to have the best implementation of click-to-play, where they'll show a plug-in icon in the address bar that the user can authorize Flash from, whereas other browser may not offer any mechanism at all in an event that the content doesn't allow them to throw a Flash permission dialog.
Anyway, the point I'm trying to drive home is that none of this is static, and that "let's ride this out" isn't a viable strategy. Chrome provides some concrete "Developer recommendations" on their guide, but you'll need to test and balance that approach with requirements imposed by the other browsers that you care about.
Thanks! We're aware of the situation and we have a mitigation plan. We currently have a lot of legacy content that we're reluctant to drop while our HTML5 offering is improving.
We'll try playing around with SWFObject2.
We've narrowed this down to an organisation admin setting in Google by following these instructions: Set Chrome policies for users - Chrome for business and education Help
There are three options for plugins (disable for all, enable for all and let the user choose). If the organisation has enabled plugins for all users
- in Chrome v.61 it allows the users to use Flash without a prompt
- in Chrome v.62 it disables Flash that's embedded using SWFObject2 on sites the user doesn't use regularly. The user has no way to re-enable it.
We've noticed that Flash embedded using the <object/> still seems to work.
Thanks for that feedback. That was my sense. Using actual object and embed tags is much easier for the browser to catch and handle vs. catching the point at which an object is inserted into the DOM at runtime (while maintaining performance).
I'll check out the SWFObject2 test suite with Chrome 62 to see if there's a reportable bug there.
There are definitely a number of other factors in play, like Chrome's Site Engagement Score. Each release bumps the required threshold value up.
In administratively controlled situations, my read of the documentation is that administrators will be required to whitelist URLs where they want Flash Player to be allowed, via the PluginsAllowedForUrls directive. I haven't played around with this yet, but if I can reproduce the SWFObject2 issue, I'll be curious to see if the whitelist allows it.