Major bug affecting IE6/7/8 and fixed in flowplayer-3.1.4.js needs to be incorporated in SWF Tools

Maybe I'm being dense but I don't see where SWFTools can do anything about this? incorporate the change where?

SWFTools requires the flowplayer to be downloaded. Fixed files from flowplayer would require you to download them from flowplayer.com and upload them to the shared folder where you installed flowplayer in swftool. The file that the bug was in (which has been fixed by flowplayer) is included in the flowplayer download.

Moving to support request at this point and hoping for more clarification.

Well, I'm using flowplayer 3.1.3 and the fix to the issue is in flowplayer-3.1.4.js. However, there is no flowplayer-3.1.3.js in my installation of flowplayer anywhere within the sfwtools folder. Therefore, that means that SWF Tools is coded to make Flowplayer work in lieu of flowplayer-x.x.x.js. Therefore, the fix needs to be incorporated in the SWF Tools flowplayer code itself (i.e. under swtools/flowplayer3).

Basically, SWF Tools flowplayer module is somehow doing what flowplayer-x.x.x.js would have done; therefore, since flowplayer-x.x.x.js is not needed by SWF Tools, the necessary code to prevent IE from caching needs to be implemented in SWF Tools itself. If flowplayer-x.x.x.js is NOT used when flowplayer is NOT implemented in the manner of the example files in the flowplayer directory, flowplayer-3.1.4.js can't be used to fix the issue. This is the case with SWF Tools. Download and extract flowplayer and you will see a directory called example. In there is flowplayer-3.1.4.min.js. But since SWF Tools does its thing without using that file, the fix, though already in flowplayer-3.1.4.min.js, must also be implemented in SWF Tools.

Hope this now makes sense.

If that still does not make sense, follow these steps and it will make sense:

1. Setup a page to display flash video using Flowplayer with SWF Tools
2. Launch the page with IE 6, 7, or 8 and play the video
3. Refresh the page. Notice now that the plug-in is blank. Flowplayer has failed to load because the swf is already cached and a bug in all IE browsers prevents the Flowplayer preloader from firing if the swf file is already in cache.
4. The solution is to prevent IE form caching the swf file, as detailed here: http://flowplayer.org/blog/43
5. Now how do you implement #4 in SWF Tools, since SWF Tools essentially does what flowplayer-x.x.x.js does and therefore, does not use any flowplayer-x.x.x.js; thus, I cannot use flowplayer-3.1.4.js, which has the fix? The fix must be introduced into SWF Tools itself.

I notice Status still says: "postponed (maintainer needs more info)"

What other info is needed?

I'll need to run some tests on this. The SWF Tools flowplayer module doesn't use the flowplayer embedding script as this is a custom embedding method specific that isn't yet supported. That's why there is nowhere to implement the new flowplayer-3.1.4.js file.

From your description it sounds like you are saying the bug occurs in SWF Tools which uses different embedding methods. If that's the case it may be possible to use the same fix that is described on the flowplayer web page by incorporating the "random string" in the flowplayer module itself.

Like I said, I'll need to investigate some more when I get a chance.

I am experiencing the same problem, but like quevo, I don't have the skills required to troubleshoot. I will add that in addition to IE, Flowplayer 3.1.3 also only works intermittently for me in Firefox 3.0.1.4 with SWF Tools. Previous versions of Flowplayer worked flawlessly with SWF for me.

Thanks for a great module!

This attached patch is my temporary solution to the problem. Please tell me if it works for you.
I did not make it configurable or conditional (to be applied for IE only), in order to keep this patch as small as possible. It is still a little bit cumbersome, only to get along with the caching of the result of module_invoke_all('swftools_methods'); This means you will have to clear the Drupal-cache at http://www.your-drupal.example.com/admin/settings/performance in order to see any changes.

Phew, my first contribution. Please bear with me.

OK - my test rig is back up and running (long story) and I can recreate this bug.

@raphaelhuefner - thanks for the patch. The concept is right, but the fix can be made more easily in one line the flowplayer3 module itself. The architecture of SWF Tools is bit complicated right now so it's not always easy to see what's going on! The shorter fix is to add

at line 106 of flowplayer3.module

BUT there's a problem - the fix won't work for people using the [swf] input filter. Drupal caches the result of the filter for performance reasons, so although an md5 hashed time is added to the resulting url, the result itself is cached. When the page is refreshed the user gets served the same hash, and the content still breaks.

The work around for THAT would be to make the SWF Tools input filter non-cacheable, so it is calculated on every page. That's easily done by changing line 1245 of swftools.module to

but once you've done that then any input format that uses SWF Tools will not be cached and you take a performance hit since everything is now recalculated for every page view.

The solution posted at FlowPlayer relies on use of their own embedding script to append the hash when the content is rendered. So the workaround concept suggested in the patch above is right (tag on some random numbers!), but it still fails for the normal use of SWF Tools.

So I'm stumped as to how to solve this. The non-cached option will "work" but at the expense of performance, but I don't see how else to tag a suitable hash on every page.

Option 2 is enable flowplayer embedding, but that's another script and a bit of a pain as it means the script becomes necessary for embedding.

Option 3 is to not use FlowPlayer 3.1.3 but use, say, 3.1.2 if you can. And then we hope they fix the bug later. The FlowPlayer website refers to other embedding methods in its documentation, so a workaround that is specific to their own embedding solution goes against that. The problem might be that they assume those using, say, SWF Object 2, will be able to add on a hash string themselves and they probably don't worry about it!

If anyone has a bright idea of a fix that avoids the non-cacheable performance hit then add it below!!

@Stuart Greenfield: Is there maybe a way you can use tagging to make using "return TRUE" or "return FALSE" conditioned on which swf module is being dealt with?

Of course, if this is going to get really ugly and if Option 3 works for people, that may be a reasonable alternative, with a note that users shouldn't use flowplayer 3.1.3. Of course this all assumes, as you alluded, that future flowplayer releases will be fixed.

Meanwhile I've worked around the issue by launching flowplayer using flowplayer-3.1.4.js via and HTML page in thickbox. So if someone doesn't require that the flowplayer swf be embedded in the page, this is one alternative.

Thinking about this some more this morning, as a stop gap I can add a setting to let the user choose to disable input caching so that at least makes it easy.

I have had some thoughts before about implementing support for the FlowPlayer embedding method as this would let users access the wider API it offers, so maybe this is a reason to do it. It would mean that you choose to embed FlowPlayer with a different embedding script to the rest of your page, but that's probably not a major blocker. It shouldn't be too hard to do, he said confidently...

In the meantime, we hope that the FlowPlayer team reverse whatever change it was that caused 3.1.3 to acquire this bug!

As a short term fix I'll go with letting users switch off caching as that cure's the immediate issue. Setting to active as I'll now work this up.

Downgrading status to normal. The bug is specific to one version of FlowPlayer only, and therefore this issue doesn't break a Drupal site. For convenience, you can get the 3.1.2 player from http://flowplayer.org/releases/flowplayer/flowplayer-3.1.2.zip.

I've made a start on implementing support for the flowplayer.js embedding script. It's not quite there yet, but I have players appearing on a page using it which is a start...

I just made a commit of the new flowplayer3 module on branch DRUPAL-6--2 if anyone wants to test it. This enables support for the flowplayer embedding JavaScript which cures the IE6/7/8 bug.

You need to install the JavaScript file at swftools/shared/flowplayer3/example/flowplayer-3.1.4.min.js. The path looks a little strange, but it basically means you can copy the contents of a flowplayer.zip download and drop it all in the flowplayer3 directory.

On the FlowPlayer3 settings page there are now a few new options. Under Player and plugin files you can configure an alternative path to the js if necessary, and while I was in there I added an option to allow an alternate control bar (e.g. tube) to be specified.

The important part is the new section Flowplayer3 embedding. Under here you need to check the option Use FlowPlayer3 embedding. That will cause FlowPlayer to be embedded using the flowplayer script, not the site wide embededing method configured on the main SWF Tools settings page.

You'll see a second option here that is already checked (Load FlowPlayers immediately). By default the flowplayer.js script doesn't actually replace the players until it's told to load them, so if you clear this option then you won't see the player until you click the container. If you look carefully at the flowplayer website you realise some of the examples use an image to represent the player. The logic is that you can prevent downloading and rendering players until you need them. I'm guessing in 99% of cases this setting should be left checked, but it's there if you want to experiment.

Once you've enabled Flowplayer3 embedding then that should be all you need to do. From the testing I've done tonight everything then seems to work as normal.

Now this code is in place it opens up the potential to support other FlowPlayer plugins, but that's for another day.

Please test and post your feedback!

@Stuart Greenfield: Just tested swftools 6.x-3.x-dev (released: September 23, 2009 - 12:04) and I can't get it to load at all in IE6 -- even after clearing cache. I get the blank where flowplayer should be. It does, however, loads in IE8 and Firefox. I haven't tried IE7.

I have enabled flowplayer embedding, as you described, and the following is what I entered into the Drupal text field:

<swf player="flowplayer3_mediaplayer" file="video.flv"></swf>

Thanks

OK - thanks for the observation about IE6. The code is still developing so maybe something isn't quite right. But as it works in IE8 and Firefox it might just be IE being awkward. No change there then :-)

I tried 6.3 Dev with IE 8 and it shows a empty flash box. It works fine with firefox and opera.

Edit: i juse the "Flash Node" modul for flash content.

On my test set up it seems to be working under IE8, but not IE7 or IE6. Firefox is ok, as is Safari.

Has anyone else tried IE6 or 7, and what happened? Anyone else try IE8 and have a problem?

Update: It works only with a empty cache and IE 8. The empty boxes appear after a reload. Looks like the cache fix doesn't work. The Javascript for flowplayer embading is activated and it works fine with other browsers.

The problem with IE6/7 seems to be passing the version parameter as part of the general flash configuration (diagnosed by manually editing a page and removing each parameter in turn).

With a modified flowplayer embedding script which strips out the version parameter it seems to be behaving better. Not sure if this is right fix, but I've committed it for now to allow ongoing testing.

The dev package will regenerate at the next run. Remember this code is in active development so various bits might break at any time! But please post feedback if you try it!

The scope of the work is expanding a bit beyond just support FP3 as the improved playlist and CCK support is looking promising.

edit
Some research at flowplayer.org suggests this might be because the flowplayer embedding method wants to receive the version number in the form [major, fix] - i.e. two integers wrapped in square braces.
/edit

Nothing has changed for me with the new version, IE 8 shows a empty flash box without the player and firefox works.

@Thurgi

What are you trying to embed? mp3? flv?

How are you trying to embed? If you're using the [swf] input filter have you cleared the Drupal cache to get rid of previous results?

Can you provide a link to the page, or paste the source code, so I can try and work out what is happening. It might be that you are using a specific configuration parameter that the code is objecting to. It's working for under IE8 quite nicely.

Have you tried clearing IE's cache - I've had trouble with scripts and swf's getting cached and not reflecting the latest changes.

You have mail :)