Can I move a Flash object within the DOM without it reloading?

Question

I'm trying to use the scale effect from the jQuery UI library on a wrapper element that contains a Flash object.

The problem I'm encountering is that the content of my wrapper is automatically moved into another wrapper (.ui-effects-wrapper), and when this happens the Flash object reloads.

Of course, the specific problem here has to do with the tactic employed by jQuery UI — but generally, is it possible to move a Flash object within the DOM without it reloading?

Radbun

Answer 1

I only know how this works in Gecko (Firefox's rendering engine). In that engine, no, you can't move an <object> or <embed> within the DOM tree without reloading the associated Flash object. It's actually worse than that: you can't do anything that would cause the CSS box drawn by the Flash object to be destroyed. Gecko treats CSS boxes as ephemeral; almost any DOM modification involving the subtree that contains the <object> will destroy the associated CSS box, and so will any number of CSS manipulations ranging from the obvious (set display:none) to the obscure (change opacity or overflow). But the state of the plugin is attached to the box tree rather than the DOM tree, so if the box is destroyed and recreated, the plugin gets reloaded.

This is agreed to be a bug — bug 90268, nine years old as of this writing. See, particularly, comment 80 for the really long explanation of why this is and why, sad to say, I would not be surprised if it went another nine years without getting fixed.

Possibly you could work around this by exporting all of your plugin state to JavaScript in the containing page.

UPDATE: Only two years later, the bug has been fixed! The fix will be in Firefox 13, currently scheduled for release on June 5, 2012; if you want it sooner, it'll be in "beta" on April 24, and "aurora" shortly after March 13 (which is today). Josh Aas deserves much credit for wrestling this one to the ground — the fix went through 54 revisions and modifies more than 3,000 lines of code.

Colly

A very informed response, thanks for your time... I particularly enjoyed reading bug 90268! While I'm not any closer to moving a Flash object, I'd say knowing limits like this one is just as important as knowing what I can do. – Radbun

You're welcome. It occurs to me that, depending on what your larger goal is, you might be able to get away with a position:absolute container whose top/left properties you manipulate from JS? – Colly

So, is this Gecko specific problem then? It doesn't happen to other browsers, right? – Premillennial

I can at least confirm that this is not a problem on Chrome, IE8+, or Opera 11+. – Illtimed

this on IE8 can cause error on calling the flash method from javascript, external methods – Selfsatisfaction

Answer 2

I do not know if you can make this work in browsers that suffer from this problem - which from some testing seems to include at the time of writing the latest versions of Chrome (Linux), Firefox (Win/Linux), Safari (Win), and Opera (Win/Linux)) - but in Internet Explorer (or at least in IE6 and IE8, on Windows XP) the Flash applet is not reloaded. However in IE there is some weirdness with SWFObject calling the 'embed' callback twice when it is reinserted into the document tree. So I've decided to just never try to do something like this and store my Flash state in JavaScript as was suggested in the first answer.

Anyways, sorry for not providing a real answer, but since this was the first google result when googling for the same problem I felt it might be usefull to list which browsers I know of that have this issue (I'd reply to jayarjo's comment but I do not have enough reputation for that yet :/)

Philipson