Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ignore primary:flash when Flash is blocked #1558

Merged
merged 1 commit into from
Nov 17, 2016

Conversation

robwalch
Copy link
Contributor

When primary: 'flash' is set, and utils.flashVersion() is not 0, embed a swf during setup that calls back to confirm the Flash plugin is not blocked. If it doesn't callback in 1.5 seconds, set primary to undefined and continue setup.

The swf being embedded is a new swf called "flash.loader.swf" and is an instance of FlashHealthCheck.as. It is < 1k in size. It's not actually loading anything - I just couldn't think of a name that described it's role that didn't sound silly or suspicious.

When embedded it fills a temporary container that is styled to match the player's dimensions. This is so that any rules applied to the size of an object tag are applied (ex: a browser may block a 5x5 swf but not a 640x360 one).

JW7-3414

@jwplayer-robot
Copy link

Automated tests passed!

Cheers! 🍻 👐

var originalContainer = _api.getContainer();
var parentElement = originalContainer.parentElement;
if (!parentElement) {
// couldn't perform test because setup container has not parent
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"has not parent"

@robwalch robwalch force-pushed the feature/flash-blocked-detection branch from a6ffd9b to 02a3792 Compare November 17, 2016 16:45
@hussam-i-am hussam-i-am merged commit 2547250 into master Nov 17, 2016
@jwplayer-robot
Copy link

Automated tests passed!

Cheers! 🍻 👐

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants