Issue metadata
Sign in to add a comment
|
Flash not honoring white list policy correctly. Users have to always manually allow when navigating between pages.
Reported by
jason.e...@ransquawk.com,
Jul 28 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.78 Safari/537.36 Example URL: https://zerohedge.talking-forex.com Steps to reproduce the problem: 1. Go to https://zerohedge.talking-forex.com in Chrome 60 2. Allow Flash (i.e. click on lock and allow it for [*.]talking-forex.com or zerohedge.talking-forex.com). The page will update and run the Flash audio player 3. However refreshing the page / navigating round page causes the blocked Flash notification to keep appearing despite the white listing. I've tried going to chrome://site-engagement and tweaking the figures in there too and that doesn't change any thing. Users of our sites have to constantly allow Flash between page loads. Chrome should pick up the fact the site is white listed and thus run Flash (despite Allow Flash is on and ask first being disabled). This affects both Linux and Windows. This has been a massive issue for us this morning as users have had their browsers quietly update to Chrome 60 overnight. What is the expected behavior? Flash should run (and thus the audio player will show up) between page navigation without constantly reminding the user to allow Flash. What went wrong? Chrome is not correctly picking up the white list rules. Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? Yes 59 Does this work in other browsers? Yes Chrome version: 60.0.3112.78 Channel: stable OS Version: Ubuntu 17.04 Flash Version: Shockwave Flash 26.0 r0
,
Jul 28 2017
OK, found a way round this, so this site is working - I've had to modify the Flash so rather than being a 1x1 px size for the embed it's needs to be something around 32px or bigger initially. Because we use JS for the UI and just use Flash for the audio we don't want the Flash component being visible so we then have JS to set the height to 0 / overflow to hidden once Flash has initialized. Previously this has always been fine at 1x1 Given this was never an issue before I do feel it's a browser regression that might need addressing as not everyone will be able to work round this. Our use case for Flash is merely the RTMP delivery (until we can allocate resources to switching to WebRTC) so the need for interaction with Flash directly from the user isn't needed.
,
Jul 28 2017
,
Jul 28 2017
Perhaps this is the change documented here? https://www.chromium.org/flash-roadmap#TOC-PPS-Tiny---No-Same-Origin-Exceptions-Target:-Chrome-60---Aug-2017-
,
Jul 28 2017
Thanks for the report. Agreed, based on the issue description this sounds like the reporter is hitting the same origin exception blocking for tiny Flash content. Please note that the site exceptions only allow for Flash player to have the ability to run on a site, they do not grant an exception from the blocking. The easiest short-term workaround would be to make the Flash content visible. In light of the recent Adobe announcement about the end of Flash support, I'd strongly recommend exploring a purely HTML based solution. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by jason.e...@ransquawk.com
, Jul 28 2017