The response from Adobe on the Adobe Forms is that a security change in Flash Player 10 prevents indirect calls display to File Dialogs.
This means that the SWFUpload JavaScript API cannot trigger the File Dialog in Flash. Which means SWFUpload is permanently broken for Flash Player 10.
We have 4 options:
1. Hope Adobe will have mercy and roll back this change and save SWFUpload.
2. SWFUpload support ends at Flash Player 9 and is not moved to Flash Player 10 (in other words, the project dies in 6 months to a year after the release of Flash Player 10).
3. Change the SWFUpload whole design philosophy dropping the JavaScript API (at least the portion that triggers File Dialogs and starts/stops/cancels uploads) and forcing a Flash Movie UI on our users.
4. Try to implement a kind of mix of Flash UI and HTML UI and complicate things by making the Flash UI configurable enough to match the HTML UI.
Unless Adobe is going to take their FileReference APIs serious and fix the bugs that are plaguing us (mod_security issues, data return issues, IO Error issues, Linux compatibility, etc) then I don't see a very bright future for any Flash based upload component. Is it worth the fight?
@skeftomai, it just doesn't work that way. The browser and the Flash Player are separate components and they touch in very limited ways. The both work to enforce security and file access is one of those places were security can be very stringent. I'm surprised that Flash allows file uploads at all.
There has been some more feedback on the Adobe forums (some good feedback show how Flickr, Yahoo, and others use this functionality). Hopefully Adobe will listen.
I would hate to have to use a Flash Movie button but we'll see.
SWFUpload will probably not die but it probably won't be Flash Player 10 compatible until version 3.
After finding the yui uploader app and coding for it, we found this. We were under the impression the yui is swfobject 1.5 and this 2.1. Are we assuming correct that SWFUpload in based on SWFObject 2.1?
Anyway, then we find this blog and find flash 10 is a show stopper.
I gotta tell ya, we really like SWFUpload, a lot.
Some of the listed "known issues" however concern us. How often do they stop the show is what we wonder? Kinda rhetorical unless someone actually has stats? Now I'm wishful.
We kinda went off half baked and coded before we read everything. oops. But did I mention we love SWFUpload?
We publish an add on photo gallery for vBulletin forum software and will have our UI put in front of a diverse collection of people, browsers and OS's. It will also be hosted on shared hosts, linux and windows hosts if we roll it out. We need a multi file, one dialog, select a lot of files, uploader in it. SWFUpload fits the bill, but...
Ok sorry for the long story, but we have a couple of questions.
Can we assume from your posts, gyphie, that no matter what happens with flash 10, ya'll are committed to adapting to it in SWFUpload? We would gladly. Moving our handlers from the 1.5 app to your 2.1 app went smooth.
Are there any known issues published that have been perhaps resolved or another place we can get more details on such things other than the html docs?
Thanks again for SWFUpload. We appreciate and look forward to working with and building on your efforts.
1. If YUI uses a version of SWFUpload then they haven't told us (there never was a SWFUpload version 1.5). But we are an open source project and they are free to use our code so long as they abide by the license.
2. We are completely unrelated to the SWFObject project but do have a Plugin that allows SWFUpload to take advantage of SWFObject. SWFObject has nothing to do with Flash based uploads.
3. All event handlers for any 2.x version of SWFUpload should be compatible. If you are moving from some another Flash based upload control to SWFUpload you will obviously not be compatible and will have to update your website accordingly.
4. There are workarounds for the Cookie issue (I hope it's fixed in FP 10 but we'll still have to deal with FP 9 for awhile). All Flash based upload tools will have the same bug so don't think this is just a SWFUpload thing. We've provided a lot of information on working around this issue.
5. We are committed to continuing SWFUpload through Flash Player 10. We are taking a 'wait and see' approach hoping that Adobe will back off a little bit and allow this and other similar projects to continue our UI Free line of development.
If not we will have to add some kind of Flash UI that allows us to trigger the file selection dialog. We have come up with 2 possible solutions:
a. Create a standard type of button image file so the developer can skin the "Select Files" button anyway they wish. This image will display inside the Flash movie and will be placed in the location you indicate on the page. Or;
b. Create a transparent Flash Movie that can be positioned and sized by the developer over the top of a page element. When the user clicks the page element they will actually be clicking the Flash Movie and triggering the Selection Dialog. If Adobe lets us get away with this then their security changes were useless anyways.
6. In my personal projects using SWFUpload I have not had any reported problems. Almost 100% of my users use Windows and Internet Explorer 6 or 7. Some use a Windows version of FireFox.
The Flash Player's Linux compatibility is extremely poor and so SWFUpload suffers. However, I believe that Linux users already understand that their chosen OS is not well supported and although they are frustrated when website don't work they are not surprised. There is little we can do to fix Flash Player for Linux bugs and so SWFUpload (and any Flash based upload) just doesn't work well for Linux users.
In all my SWFUpload projects I always provide a way for the user to manually fall back to a standard upload form if they are having trouble with SWFUpload. And I have not received a single complaint that they could not upload the file they wanted. These are relatively small projects with 50 ~ 100 users.
7. Your hosting provider should not affect the operation of SWFUpload in most cases. There are a few uncommon (not Apache/IIS) web servers that are too strict for Adobe's upload implementation in the Flash Player but usually they can be configured to allow SWFUpload to operate (I consider this advanced work that is beyond the scope of support that we can provide here). The mod_security module for Apache has caused us some trouble but we believe we've provided enough support, documentation and sample files that most users should be able to configure there site to handle those issues. Note: All Flash Based upload tools will suffer from these same issues.
-----
We are very proud of the work we've done on SWFUpload, especially all the effort and creativity we have in working around the myriad of bugs in the Flash Player itself. We hope the show-stopper issues in Flash Player 10 can be resolved soon so we can move on to fun stuff like client side thumbnails and image resizing.
We hate taking black eyes for Adobe's bugs and we understand your frustration but a lot of times all we can do is provide less than satisfactory work around or pass the buck.
Hello guys and Thanks for this great Uploader! I am currently developing powerful Image Sharing site and the project require powerful and secure uploader as SWFUpload, but the problem with FF3 is not nice
For now all customers & visitors can fix this by installing this addon https://addons.mozilla.org/en-US/firefox/addon/1879 (don't forget to enable it after firefox Restart after installation!)
it fixes for now the problem with firefox and hopefully Adobe will do their best soon.
Adobe will take care for this problem they won't let this issue to stop this technology, Huge sites like Flickr use similar based uploader and I am sure they already think about this. Still v10 is Beta version, not official release, I am sure until their official release of v10 they'll fix all common issues with flash player. Current official release is v9 and still working with this MediaWrapper. So there is no problem for now Keep doing your great job!
What if you set SWFU to trigger the dialog when a flash button is clicked, and then you use ExternalInterface to trigger the click event? Is such foxery possible?
I had a deployment of SWFUpload ready to go live, but I'm holding off while this issue is resolved. I've told Adobe what I think of the amount of effort their decision has wasted, but I doubt there will be change of course.
I'm not sure whether transparently overlaying the HTML "browse.." button will work in all browsers, and it might later come to be seen as yet another a "security issue" by Adobe.
Would it be possible to pass custom "browse..." button images in as parameters? Then it would be fairly easy to create images to match the css styles used elsewhere on a page, especially if the "sliding doors" technique was being used on other buttons.
I've done some testing on solutions and the only that seems reasonable so far is:
Add a parameter to an Image file that represents the button. Also require desired width and height parameters. One more parameter indicates where to inject the flash file.
The image would be a sprite with 4 "panels". Each panel would contain a button state (up, over, down, disabled) so the button will animate properly.
Now we are trying to decide whether to just patch this in to v2.1 (making v2.2) or to do our "rewrite" and produce v3.0. The developers don't have a lot of time for a rewrite and the Flash 10 release seems imminent so we'll probably do a v2.2 release (which I hate to do because the API/behavior is changing so much).
Which ever way we go we will likely drop Flash Player 8 support in the next release.
Thanks a lot for your great work!
I must say, I would *really* prefer a text button, because image buttons are very difficult to translate. Please provide a text-button.
Thanks a lot!
your suggestion sounds good, though I have to agree with Double that passing a text would be easier for multilingual websites... (less images)
How about passing a (background) image AND a text? (perhaps with some basic style attributes like font-size, color and font-family?) This way we wouldn't have to create one image per language or button label. (In my case the label varies per page)
If that'd be possible I not afraid anymore of the "security change" in flash10.
Gyphie, I like q_no's suggestion/arguments too, but once we contemplate text-over-a-button, things can/should get more complicated, fast.
I would suggest sticking to your original concept (image-panels) for a 2.2 patch, then contemplate building something more flexible (if you're all still interested!). Adding text will quickly necessitate:
a) a sliding-doors type technique (so that our buttons can scale to fit different lengths of text)
b) a font parameter, so that we can point to a .swf with our font of choice (like SiFR)
c) basic HTML/CSS flexibility (passing italicized words, allowing line breaks, controlling line height, tracking [letter spacing], etc.)
All of those features would be great (if you want to program them)... but I'd much sooner see a simple 2.2 image-panel update.
We all appreciate the adaptability and hard work of the swfUpload team. THANKS.
p.s. I've done some more reading over the web, and no, I don't think Adobe will be changing their mind on this one.
I also made heavy use of SWFUpload in the past and you can imagine that I am also very unamused of Adobe's security-change. This change will brake a significant part of the pages I made over the last two years, as well as numerous CMS using SWFUpload. Therefore I followed this thread closely for some time. And now that it get's appearant that Adobe will follow its new route, I also thought about a fix.
In my opinion, passing an image is unsatisfactory for the designer, as is the parameter-way for the SWFUpload-developer(s). So I developed a third way, that doesn't need a change to the original HTML layout and styles: I wrote a little script that overlays the input-element triggering the file-browser with a div-element. This div-element adepts to the dimensions of the input beneath. As it covers the input, the latter cannot be pressed anymore. Instead, the div can now be used to embed (with the help of SWFobject) a Flash-movie with wmode set to "transparent", stretching to the div's dimensions (already determined in my script) and with an invisible button inside, triggering the file-browser in an "allowed way".
This solution still requires SWFUpload to be modified (adding the button, including this script into the SWFUpload-scripts) but I think it retains the former flexibilty and limits the reengineering-work on both sides.
I had hoped to do both. The element placement code is all JavaScript and can easily be modified or adapted with a plugin. The button code is in the SWF and should be identical for both methods.
I like the overlay method but it has some potential issues: 1) A little tougher to make cross browser, 2) blocks UI interaction (no visual button hover or click)
The image method also has its issues: 1) Loss of OS consistancy 2) even more loading delay (page loads -> swfupload loads -> button image loads).
@gyphie, I don't have a problem with the overlay if the developers want to invest the time, but I thought you hinted at an interesting problem back in your July 29th comment: surely fully transparent clickable SWFs will one day be considered a security-risk as well! (they deceive the user as to what they are interacting with.) Then we'll be back where we are today, having to maintain/re-fix pages we've built over the last few years.
Anyhow, the transparent solution's main advantage - that HTML buttons will look like they should on each platform - is pretty much nullified by the fact that those buttons won't ACT like they should on each platform, when under a transparent SWF... as you've noted, no rollover or click states!
Security Change
The response from Adobe on the Adobe Forms is that a security change in Flash Player 10 prevents indirect calls display to File Dialogs.
This means that the SWFUpload JavaScript API cannot trigger the File Dialog in Flash. Which means SWFUpload is permanently broken for Flash Player 10.
We have 4 options:
1. Hope Adobe will have mercy and roll back this change and save SWFUpload.
2. SWFUpload support ends at Flash Player 9 and is not moved to Flash Player 10 (in other words, the project dies in 6 months to a year after the release of Flash Player 10).
3. Change the SWFUpload whole design philosophy dropping the JavaScript API (at least the portion that triggers File Dialogs and starts/stops/cancels uploads) and forcing a Flash Movie UI on our users.
4. Try to implement a kind of mix of Flash UI and HTML UI and complicate things by making the Flash UI configurable enough to match the HTML UI.
Unless Adobe is going to take their FileReference APIs serious and fix the bugs that are plaguing us (mod_security issues, data return issues, IO Error issues, Linux compatibility, etc) then I don't see a very bright future for any Flash based upload component. Is it worth the fight?
Oh.my god
hi, gyphie
that's too bad, have you got any resault from adobe?
Surely there has to be another way...
There is always another way. Maybe they just changed how it works?
Maybe a solution would be to turn the "Browse..." button could be turned into a Flash movie button that when clicked shows file dialog?
Have you asked Adobe about a workaround?
PLEASE don't end this project. Let's find a solution.
Maybe something similar to
this? http://www.pixeline.be/experiments/jqUploader/test.php
This uses a flash movie for the Browse button.
Normal "file" input field?
Hmm...can swfupload not just use a normal "file" input field? Why must the file dialog be displayed via Flash?
RE:Normal "file" input field?
You can not specify the file type filter when you using normal file input field, this feature also is useful.
Doesn't work that way
@skeftomai, it just doesn't work that way. The browser and the Flash Player are separate components and they touch in very limited ways. The both work to enforce security and file access is one of those places were security can be very stringent. I'm surprised that Flash allows file uploads at all.
Feedback to Adobe
There has been some more feedback on the Adobe forums (some good feedback show how Flickr, Yahoo, and others use this functionality). Hopefully Adobe will listen.
I would hate to have to use a Flash Movie button but we'll see.
SWFUpload will probably not die but it probably won't be Flash Player 10 compatible until version 3.
oh bummer
I can't believe this change - or in other words: I don't want to believe it!
Hopefully Adobe will listen to their users, otherwhise I'll have to put them on my "hate list" right after IE6/7.
If Adobe would keep this change, will flash10 be backwards compatible anyway? Or will all of our uploads forms just fail?
...disappointed
q_no
Just Fail
The current Flash Player 10 beta just fails.
adobe forums
can you perhaps provide some links the adobe forums regarding this issue? I couldn't find anything related to flashplayer 10 and file uploads :-|
Adobe 10 Status
After finding the yui uploader app and coding for it, we found this. We were under the impression the yui is swfobject 1.5 and this 2.1. Are we assuming correct that SWFUpload in based on SWFObject 2.1?
Anyway, then we find this blog and find flash 10 is a show stopper.
I gotta tell ya, we really like SWFUpload, a lot.
Some of the listed "known issues" however concern us. How often do they stop the show is what we wonder? Kinda rhetorical unless someone actually has stats? Now I'm wishful.
We kinda went off half baked and coded before we read everything. oops. But did I mention we love SWFUpload?
We publish an add on photo gallery for vBulletin forum software and will have our UI put in front of a diverse collection of people, browsers and OS's. It will also be hosted on shared hosts, linux and windows hosts if we roll it out. We need a multi file, one dialog, select a lot of files, uploader in it. SWFUpload fits the bill, but...
Ok sorry for the long story, but we have a couple of questions.
Can we assume from your posts, gyphie, that no matter what happens with flash 10, ya'll are committed to adapting to it in SWFUpload? We would gladly. Moving our handlers from the 1.5 app to your 2.1 app went smooth.
Are there any known issues published that have been perhaps resolved or another place we can get more details on such things other than the html docs?
Thanks again for SWFUpload. We appreciate and look forward to working with and building on your efforts.
Greg
Never mind, the cross
Never mind, the cross browser cookie issue closed the show. We can't use this as a result.
Maybe Flash 10 will fix that and we can revisit this.
Regards.
Adobe Flash Player 10 forums
Adobe Flash Player 10 forums (this links to the most pertinent thread):
http://www.adobe.com/cfusion/webforums/forum/messageview.cfm?forumid=72&...
-------
GregL:
1. If YUI uses a version of SWFUpload then they haven't told us (there never was a SWFUpload version 1.5). But we are an open source project and they are free to use our code so long as they abide by the license.
2. We are completely unrelated to the SWFObject project but do have a Plugin that allows SWFUpload to take advantage of SWFObject. SWFObject has nothing to do with Flash based uploads.
3. All event handlers for any 2.x version of SWFUpload should be compatible. If you are moving from some another Flash based upload control to SWFUpload you will obviously not be compatible and will have to update your website accordingly.
4. There are workarounds for the Cookie issue (I hope it's fixed in FP 10 but we'll still have to deal with FP 9 for awhile). All Flash based upload tools will have the same bug so don't think this is just a SWFUpload thing. We've provided a lot of information on working around this issue.
5. We are committed to continuing SWFUpload through Flash Player 10. We are taking a 'wait and see' approach hoping that Adobe will back off a little bit and allow this and other similar projects to continue our UI Free line of development.
If not we will have to add some kind of Flash UI that allows us to trigger the file selection dialog. We have come up with 2 possible solutions:
a. Create a standard type of button image file so the developer can skin the "Select Files" button anyway they wish. This image will display inside the Flash movie and will be placed in the location you indicate on the page. Or;
b. Create a transparent Flash Movie that can be positioned and sized by the developer over the top of a page element. When the user clicks the page element they will actually be clicking the Flash Movie and triggering the Selection Dialog. If Adobe lets us get away with this then their security changes were useless anyways.
6. In my personal projects using SWFUpload I have not had any reported problems. Almost 100% of my users use Windows and Internet Explorer 6 or 7. Some use a Windows version of FireFox.
The Flash Player's Linux compatibility is extremely poor and so SWFUpload suffers. However, I believe that Linux users already understand that their chosen OS is not well supported and although they are frustrated when website don't work they are not surprised. There is little we can do to fix Flash Player for Linux bugs and so SWFUpload (and any Flash based upload) just doesn't work well for Linux users.
In all my SWFUpload projects I always provide a way for the user to manually fall back to a standard upload form if they are having trouble with SWFUpload. And I have not received a single complaint that they could not upload the file they wanted. These are relatively small projects with 50 ~ 100 users.
7. Your hosting provider should not affect the operation of SWFUpload in most cases. There are a few uncommon (not Apache/IIS) web servers that are too strict for Adobe's upload implementation in the Flash Player but usually they can be configured to allow SWFUpload to operate (I consider this advanced work that is beyond the scope of support that we can provide here). The mod_security module for Apache has caused us some trouble but we believe we've provided enough support, documentation and sample files that most users should be able to configure there site to handle those issues. Note: All Flash Based upload tools will suffer from these same issues.
-----
We are very proud of the work we've done on SWFUpload, especially all the effort and creativity we have in working around the myriad of bugs in the Flash Player itself. We hope the show-stopper issues in Flash Player 10 can be resolved soon so we can move on to fun stuff like client side thumbnails and image resizing.
We hate taking black eyes for Adobe's bugs and we understand your frustration but a lot of times all we can do is provide less than satisfactory work around or pass the buck.
FireFox problem resolved by Firefox side!
Hello guys and Thanks for this great Uploader! I am currently developing powerful Image Sharing site and the project require powerful and secure uploader as SWFUpload, but the problem with FF3 is not nice
after installation!)
For now all customers & visitors can fix this by installing this addon https://addons.mozilla.org/en-US/firefox/addon/1879 (don't forget to enable it after firefox Restart
it fixes for now the problem with firefox and hopefully Adobe will do their best soon.
Tested with FF 3.0.1
Flash Player 8.0 r22
Works perfectly!
RE: masterdev
I'm not sure what an ActiveX wrapper plugin fixes with regard to FireFox/Flash player and what it has to do with Flash Player 10.
Will be fixed
Adobe will take care for this problem they won't let this issue to stop this technology, Huge sites like Flickr use similar based uploader and I am sure they already think about this. Still v10 is Beta version, not official release, I am sure until their official release of v10 they'll fix all common issues with flash player. Current official release is v9 and still working with this MediaWrapper. So there is no problem for now
Keep doing your great job!
Event chaining...
What if you set SWFU to trigger the dialog when a flash button is clicked, and then you use ExternalInterface to trigger the click event? Is such foxery possible?
Don't count on Adobe changing their minds
I had a deployment of SWFUpload ready to go live, but I'm holding off while this issue is resolved. I've told Adobe what I think of the amount of effort their decision has wasted, but I doubt there will be change of course.
I'm not sure whether transparently overlaying the HTML "browse.." button will work in all browsers, and it might later come to be seen as yet another a "security issue" by Adobe.
Would it be possible to pass custom "browse..." button images in as parameters? Then it would be fairly easy to create images to match the css styles used elsewhere on a page, especially if the "sliding doors" technique was being used on other buttons.
Probable solution
I've done some testing on solutions and the only that seems reasonable so far is:
Add a parameter to an Image file that represents the button. Also require desired width and height parameters. One more parameter indicates where to inject the flash file.
The image would be a sprite with 4 "panels". Each panel would contain a button state (up, over, down, disabled) so the button will animate properly.
Now we are trying to decide whether to just patch this in to v2.1 (making v2.2) or to do our "rewrite" and produce v3.0. The developers don't have a lot of time for a rewrite and the Flash 10 release seems imminent so we'll probably do a v2.2 release (which I hate to do because the API/behavior is changing so much).
Which ever way we go we will likely drop Flash Player 8 support in the next release.
You are great gyphie
Thanks a lot for your great work!
I must say, I would *really* prefer a text button, because image buttons are very difficult to translate. Please provide a text-button.
Thanks a lot!
sounds good
Hi Gyphie,
your suggestion sounds good, though I have to agree with Double that passing a text would be easier for multilingual websites... (less images)
How about passing a (background) image AND a text? (perhaps with some basic style attributes like font-size, color and font-family?) This way we wouldn't have to create one image per language or button label. (In my case the label varies per page)
If that'd be possible I not afraid anymore of the "security change" in flash10.
Thanks!
Steffen
Good suggestions
Those are good suggestions (with good arguments behind them (even better!)). We'll see if we can make that work.
Evil Adobe!
:@
Simple first, then build on it
Gyphie, I like q_no's suggestion/arguments too, but once we contemplate text-over-a-button, things can/should get more complicated, fast.
I would suggest sticking to your original concept (image-panels) for a 2.2 patch, then contemplate building something more flexible (if you're all still interested!). Adding text will quickly necessitate:
a) a sliding-doors type technique (so that our buttons can scale to fit different lengths of text)
b) a font parameter, so that we can point to a .swf with our font of choice (like SiFR)
c) basic HTML/CSS flexibility (passing italicized words, allowing line breaks, controlling line height, tracking [letter spacing], etc.)
All of those features would be great (if you want to program them)... but I'd much sooner see a simple 2.2 image-panel update.
We all appreciate the adaptability and hard work of the swfUpload team. THANKS.
p.s. I've done some more reading over the web, and no, I don't think Adobe will be changing their mind on this one.
good suggestions!
@gyphie thanks a lot for the great work on flash 10 compatibility. the image-passing solution would work perfectly for us.
eta?
What's your estimated timeline for releasing a version with this workaround?
Possible quick and non-invasive fix?
Hey together,
I also made heavy use of SWFUpload in the past and you can imagine that I am also very unamused of Adobe's security-change. This change will brake a significant part of the pages I made over the last two years, as well as numerous CMS using SWFUpload. Therefore I followed this thread closely for some time. And now that it get's appearant that Adobe will follow its new route, I also thought about a fix.
In my opinion, passing an image is unsatisfactory for the designer, as is the parameter-way for the SWFUpload-developer(s). So I developed a third way, that doesn't need a change to the original HTML layout and styles: I wrote a little script that overlays the input-element triggering the file-browser with a div-element. This div-element adepts to the dimensions of the input beneath. As it covers the input, the latter cannot be pressed anymore. Instead, the div can now be used to embed (with the help of SWFobject) a Flash-movie with wmode set to "transparent", stretching to the div's dimensions (already determined in my script) and with an invisible button inside, triggering the file-browser in an "allowed way".
This solution still requires SWFUpload to be modified (adding the button, including this script into the SWFUpload-scripts) but I think it retains the former flexibilty and limits the reengineering-work on both sides.
You can find the working-principle under the following link:
http://www.pimpmylaptop.de/swfupload/
For a better visualization of the overlay-div you will find it colored in a transparent red.
What do you think? Might this work?
Regards from Germany
Christian
Both?
I had hoped to do both. The element placement code is all JavaScript and can easily be modified or adapted with a plugin. The button code is in the SWF and should be identical for both methods.
I like the overlay method but it has some potential issues: 1) A little tougher to make cross browser, 2) blocks UI interaction (no visual button hover or click)
The image method also has its issues: 1) Loss of OS consistancy 2) even more loading delay (page loads -> swfupload loads -> button image loads).
I'm pretty sure we can do both.
transparent swf over div will haunt us someday
@gyphie, I don't have a problem with the overlay if the developers want to invest the time, but I thought you hinted at an interesting problem back in your July 29th comment:
surely fully transparent clickable SWFs will one day be considered a security-risk as well! (they deceive the user as to what they are interacting with.) Then we'll be back where we are today, having to maintain/re-fix pages we've built over the last few years.
Anyhow, the transparent solution's main advantage - that HTML buttons will look like they should on each platform - is pretty much nullified by the fact that those buttons won't ACT like they should on each platform, when under a transparent SWF... as you've noted, no rollover or click states!
just my 2¢