Also, for k12.com to work, need to set chrome://flags/#run-all-flash-in-allow-mode to 'Enabled'.

I suspect the 'cross origin' nature of k12.com is the problem???

After signing into the K12 OLS, the web site is "lrnx.k12.com".  Clicking on the green padlock and selecting 'Allow' for 'Flash' does NOT fix the problem.  Flash context on the web page still does not run (it has a 'click to play' arrow).  The flash content is coming from static.k12.com.

Going to static.k12.com and setting 'Flash' to 'Allow' for that domain -- and then going back to the OLS main web page does not help the problem.  Flash still does not run.

How can cross-origin flash be enabled for k12.com?

Can the rules for Flash content deemed unimportant be relaxed to exclude 'cross origin' flash from the SAME top level domain?

Why is a cross domain plugin, whose (cross) domain is expressly in the "allow" list (and when the cross domain is gone to directly the plugin runs and works) not allowed to be directly run in another domain (this second domain is also expressly in the "allow" list so local plugins do run directly)?

Namely, there are two domains, both in the "allow" list.  Go to either domain individually and plugins run and work.  But go to one domain that embeds from the other domain, and things stop working.

Was this behavior by design or an error?

If the behavior was 'by design', why (since both domains are in fact in the 'allow list')?

However, if this behavior is in error, can this be fixed ASAP (and pushed into 61)?  Because this (add a couple of domains into the 'allow' list) then becomes a possible workaround/fix solving the k12.com issue.

The behavior described (i.e., blocking small same origin Flash content) is working as intended (1) and was announced back in January(2).  Tiny pixels (previously accounting for about 90% of total Flash usage) were primarily used by ad networks to aggressively track users and detect whether or not an ad was on the screen.  Given the significant implications for privacy and performance, I don't foresee us walking back this change.

A work around, for developers, that will last through the duration of Flash support would be to make the content visible (i.e., greater than 300x400).


(1) - https://www.chromium.org/flash-roadmap#TOC-PPS-Tiny---No-Same-Origin-Exceptions-Target:-Chrome-60---Aug-2017-
(2) - https://groups.google.com/a/chromium.org/forum/#!msg/chromium-dev/Elg7Vhpeb38/zQCvXQ_vAAAJ

The content is very visible (200x200), is cross origin, and the cross origin is in the allow list -- but the plugin does not run.

No, not 'same origin' -- cross origin.  See comment #6 above.

I have 'domain1' in the allow list.  Going to domain1 and running a 159x91 plugin works.

I have 'domain2' in the allow list.  Going to domain2 and running a 159x91 plugin works.

I now go to 'domain2' and run/embed the 159x91 plugin from 'domain1' (cross origin issue) -- it does not run, even though BOTH domain1 and domain2 are in the 'allow' list.

Here is a test case (using Adobe's 'about' SWF) -- all flash plugins are sized to 390 x 290.

1. Visit https://www.duckware.com/flash/du.html, and 'click to run' and select 'allow'
2. Visit https://www.vsynctester.com/flash/vs.html, and 'click to run' and select 'allow'
3. Exit and re-run Chrome
4. Confirm chrome://settings/content/flash allow list is: (1) https://www.duckware.com:443, (2) https://www.vsynctester.com:443
5. Visit https://www.duckware.com/flash/du.html and flash works/runs with no interactions
6. Visit https://www.vsynctester.com/flash/vs.html and flash works/runs with no interactions

But visit https://www.duckware.com/flash/vs.html (same vs.html as on vsynctester.com) and flash plugin is not running, even though user intent is that it should be run with no user interactions (both duckware.com and vsynctester.com are in allow list).

Close this issue.  Test case has been moved to  issue 760189 

We started blocking cross-origin small form factor Flash Content (smaller than 300x400) starting in Chrome 53 (Sept 2016)[1].  In Chrome 59 (June 2017) we removed a case that allowed unsized/ hidden Flash content to run[2], followed by the cross origin changes in Chrome 60.

We are currently considering whether to add an Enterprise policy to allow administrators to permit tiny flash content to run w/ out prompting, which should help schools and make the guidance simpler (i.e., toggling one setting versus determining precise origins to add exceptions for).  Filed as  issue 760201 .

For applications targeting general consumers, my advice would be to make the Flash content > 300 by 400 pixels to avoid the secondary blocking.  Due to privacy and performance concerns, I don't foresee us revisiting that policy.


[1] - https://www.chromium.org/flash-roadmap#TOC-Plugin-Power-Savings-Mode---Tiny-Shipped:-Chrome-53---Sept-2016-
[2] - https://www.chromium.org/flash-roadmap#TOC-PPS-Tiny---Remove-Un-sized-0x0-or-hidden-content-Exceptions-Target:-Chrome-59---June-2017-