Flash is enabled but I still get the enable Flash notification (chrome os)

[m1357]

Hi,

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 27.0.0.183. 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. 

[jeromiec83223024]

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.

[Timbolio]

Hi jeromiec83223024

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?

Thanks!

[jeromiec83223024]

First things first, we have to acknowledge the situation.  Each major US browser vendor is making changes that make Flash Player click-to-play.  The intent is to increase friction for your end-users, with the explicit goal of forcing you to an implementation built exclusively on HTML and JavaScript.

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.  [1] [2]

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.

Anyway, the thing that seems to trip up the click-to-play implementations in browsers now usually has to do with how clever you're being about inserting the <object> / <embed> tags into the DOM.  If you're doing a bunch of stuff in JavaScript to dynamically insert those objects, you might consider using the SWFObject2 library instead of whatever you're doing now, and/or simply put the tags in the HTML, and see if that improves the experience.

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.

[1] - Plugin Roadmap for Firefox - Plugins | MDN

[2] - Flash Roadmap - The Chromium Projects

[Timbolio]

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.

[Timbolio]

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.

[jeromiec83223024 · Accepted solution]

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. 

Thanks!