Race condition? VASTClient.getVASTAd.validateAd

[lpender]

FlashTester.js has a probable race condition.

When I run my site in Chrome, about 40% of the time I receive this:

AD ERROR: VAST Error: on VASTClient.getVASTAd.validateAd, could not find MediaFile that is supported by this video player VASTError Array[1]

However, if I step through the constructor of FlashTester.js, the SWF loads successfully 100% of the time.

Here are the actual results of a recent test:

no step through

1: works
2: fails
3: works
4: fails
5: works
6: works
7: fails
8: works
9: fails
10: works

step through

1: works
2: works
3: works
4: works
5: works
6: works
7: works
8: works
9: works
10: works

[Fetz]

How are you testing if the FlashTester has or not a race condition?

Is your video auto playing?

[lpender]

Hey!

Yes, it is autoplaying.

Race condition symptoms:

• Brittle pass//works sometimes doesn't work other times
• Works consistently when I step through the code, indicating that time is a factor

Reading through the code, it looks like:

• the default is to false at creation, and then
• asynchronously set to true (via a callback and a number of functions wrapped in timeouts).

The async nature of this makes it tricky, but I'm guessing this requires some sort of promise implementation.

[Fetz]

Why the flashtester?

Because browsers are deprecating flash (and some big security issues with old versions of flash), Firefox validates the flash player version and if is old for security reason he blocks it by default. So sadly all swfobject validations to check if the user has flash player will still give false positive (because yes the user has flashplayer, and yes the minimum flash player version necessary for the player).

Why is async

So to test if is supported, the test will load, VPAIDFlash (only once for all the videoplayers in the page) and that flash will try to communicate with the JS handler (this is done using ExternalInterface AS3). If this communication is successful. The we assume that flash is supported.

[lpender]

I see. Yes, flash is on the out and outs 👎

It would also be quite tricky to rewrite this method with an asynchronous promise or callback implementation as it has many downstream dependencies that would also have to be updated.

That said, it doesn't feel particularly sound design to have it only fail in a very very few edge cases (Firefox, bad flash version, autoplay, race condition).

What if we were to simply require a higher version of flash if the user has Firefox installed??

[iq-dot]

Hi @Fetz I am having a similar problem and what I am trying to do is hook into the asyn and find where the communication is successful / unsuccessful.

So far when the communication is successful, the _handshake function gets called and I can see a value, so thats great.

The problem however is I don't see any feedback when the communication has failed, most likely because flash is disabled / not installed. So is there a hook for this? A callback that happens when communication failed?