IE7 bug with dynamically adding "swfobject.js" to the page.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Dynamically add "swfobject.js" to the DOM, either while it's loading, 
or after it has loaded, instead of using a <script> tag reference.
2. Try to use it.
3.

What is the expected output? What do you see instead?
I expected swfobject to work.  it fails to add the swf to the page, ONLY 
in IE (v7 is all i've tested).  In Firefox 2.0, it works fine no matter 
how the swfobject.js file is added to the page.

What version of the product are you using? On what operating system?
swfobject 2.0 rc1, IE 7, Firefox 2.0, Win XP SP2

Please provide any additional information below.

If you dynamically add the reference to swfobject.js to your page using 
something like:

var blah = document.createElement("script");
blah.src = "swfobject.js"
document.getElementsByTagName('head')[0].appendChild(blah);

Something about the library apparently fails to initialize in IE7, but 
this same approach works fine in Firefox 2.0.

I set up two simple test files to illustrate this issue:

http://www.getify.com/swfobject/test-swfobject-works.html

http://www.getify.com/swfobject/test-swfobject-broken.html

If you do a view-source on those two, you'll notice the only difference is 
how the swfobject.js file gets loaded onto the page.  Both tests try to 
load the test.swf provided with the library download onto the page when 
you click the "here" link.  In IE7, one works, one does not.  No errors 
seemed to be issued either.  But in Firefox 2.0, both work.

Original issue reported on code.google.com by get...@gmail.com on 14 Jan 2008 at 10:55

[GoogleCodeExporter]

Similar discussion as issue #29, I don't consider this as a SWFObject specific 
bug,
but as a web authoring/IE bug. IE's DOM + DOM methods are extremely buggy, so 
as a
web author you cannot expect that everything works according to the book. If you
create extreme test cases you are bound to find bugs, however always ask 
yourself
what is the cause of these bugs.

Original comment by bobbyvandersluis on 15 Jan 2008 at 9:27

• Changed state: Invalid

[GoogleCodeExporter]

i hardly think that using the test files and code provided by library, and 
simply 
changing the way a script is added to the DOM is an "extreme" case.  There are 
thousands of examples of adding scripts to pages dynamically that work fine in 
IE.  
Look at all the major libraries, like google, yahoo, etc, they all do this in 
some 
form or fashion.

Buggy DOM methods or not, IE is IN FACT capable of adding scripts dynamically 
to the 
DOM just fine.  There's just something about the initialization of swfobject 
that 
doesn't seem to work well with it.

Is it because swfobject.js actually changes something about the DOM, or relies 
on 
the DOM loading event to do some of its work?  Perhaps.

But one would have to ask this question... IF that is true (which I don't know 
because I haven't deconstructed your library), then why is Firefox able to do 
the 
same method just fine, but not IE?  Is it possible that there's some easy 
workaround 
to the loading/initializing code in swfobject that could be adjusted to help it 
work 
if it's added to a DOM dynamically?

You can sit there and blame IE all you want (and I don't entirely disagree with 
you), but you're a very unhelpful library author if you're only willing to 
adjust 
your library for IE bugs that YOU feel are legitimate, but strike down when 
anyone 
else finds an IE bug or quirk that perhaps your library could be adjusted to 
help.  
There are LOTS of IE bugs that you have fixed with this library, I don't 
understand 
why you'd be so unwilling to look at maybe fixing another one?

How about being helpful, and trying to see if there's anyway the implementation 
could be adjusted so the script could be dynamically added to IE like it can to 
Firefox, instead of just assuming that noone would ever want to do this, and 
just 
ignoring a simple, valid report of the behavior.

Original comment by get...@gmail.com on 15 Jan 2008 at 2:54

[GoogleCodeExporter]

I've been able to track down so far that the difference in IE between the two 
ways 
of adding swfobject.js to the page lies in the fact that the function 
callDomLoadFunctions() never gets called in the dynamic case.  It would seem 
almost 
certainly this is the cause of the swfobject library not being fully 
ready/initialized.

I'm trying to track down in your library how that function gets executed so I 
can 
see what's failing.  It appears there are several places it gets called, so I 
don't 
know yet which one is the problem.

Any help you could provide in me understanding how swfobject initializes itself 
on 
page load (even before being used) would be appreciated.

Original comment by get...@gmail.com on 15 Jan 2008 at 3:21

[GoogleCodeExporter]

One note that you might consider as a "bug fix"... according to lots of 
websites, 
including:  http://www.webmasterworld.com/forum91/2913.htm  There is reason to 
believe that doing a document.write("<script.......") is not "safe" on 
computers 
where Norton is installed.  So, lots of libraries do something like 
document.write
("scr"+"ipt........") just so the Norton regex checker ignores that and doesn't 
mess 
with it.  For your library, where it does the document.write() of 
__ie_ondomload, 
you might want to consider just adding the "+" between the r and the i of 
"script", 
like Dojo does.

Original comment by get...@gmail.com on 16 Jan 2008 at 1:16

[GoogleCodeExporter]

So I tracked down that the problem I'm seeing with dynamically loading the 
swfobject.js library is that the library relies on being able to 
document.write() 
the script tag "__ie_ondomload", and attach the onreadystatechange handler to 
it to 
test when IE's DOM has loaded, and thus call the "callDomLoadFunctions()" 
function.  

However, if swfobject is being added to the DOM dynamically, this 
document.write() 
appears to not actually add anything to the DOM (in IE), or if it does, at 
least the 
onreadystatechange never fires, like it should, so swfobject never gets fully 
initialized.

Also, I found that even though Firefox worked fine when swfobject.js was added 
dynamically DURING loading of the DOM, it failed if added after the DOM, in the 
same 
way that IE failed for both cases.

Moreover, if swfobject.js were added AFTER the DOM was already loaded, I would 
think 
the document.write() *could* mess things up for IE as the document stream is 
already 
written and closed, and so another write() might try to overwrite the DOM 
(rather 
than append to it) or something of that nature.

Fortunately, I think I've found a "solution" of sorts for both cases. I found 
that 
by adding the "callDomLoadFunctions" function to the returned public API for 
the 
swfobject, I can add swfobject.js dynamically to the DOM (either during load, 
or 
after load), and with a simple setTimeout() loop, check to make sure that 
swfobject 
fully loads, and then manually call the "callDomLoadFunctions" function.  This 
fully 
initializes the dynamically loaded swfobject.js library, and allows me to use 
it 
right away as desired.

It only required a simple addition of 
"callDomLoadFunctions:callDomLoadFunctions," 
anywhere in the return value for the public API section, so that it could be 
called 
on the public "swfobject" variable.

Is this something you would consider adding to the library so I didn't have to 
be 
working on a "hacked" version of it to use the library as I need to?

Original comment by get...@gmail.com on 16 Jan 2008 at 1:23

[GoogleCodeExporter]

I have read your comments, however I see no reason to revise my standpoint.

If you use the library in a non-prescribed and irregular way, it may work, and 
it may
not: we cannot support every possible scenario. Again, when it comes to both
embedding plug-in content and advance DOM + standards, IE is an outdated, buggy 
and
proprietary piece of machinery that requires sheer workarounds and code 
forking. One
of them is the hack we need to use to simulate a DOMContentLoaded event, which 
is
currently the best solution available. Just accept this.

Now, we are very happy with all feedback and it is your good right to convince 
us
that we are wrong. However we also hope that you respect that sometimes we have 
a
different opinion and trust us on our calls. Furthermore I want to stress out 
that
this is a bug report system and not a discussion forum, and that for this bug 
tool
there is a fine line between commenting and spamming. If you feel the need to
discuss/share items with other people, please use the SWFObject discussion 
group on
Google groups instead.

Original comment by bobbyvandersluis on 19 Jan 2008 at 11:03

[GoogleCodeExporter]

I'm dubious as to why my comments would be considered spamming.  My last 
comment was 
NOT intended to debate anymore the point of whether or not this is a legitimate 
bug 
that you and your development team could or should address.  But since I'm 
misunderstood on my intent, let me state it again:  I disagree with you, but 
there's 
no further reason to debate it.  That is not the reason for me writing right 
now.

HOWEVER, there's an unresolved question at the end of that last post that you 
didn't 
address directly.  As stated, I found that the callDomLoadFunctions() function 
wasn't getting called automatically in my "extreme/irregular" scenario, but as 
a 
workaround to my problem, if I could call it manually (since my scenario gives 
me 
other ways to detect such an event), I could still use your library without any 
problems, on all browsers.

The only problem is that this function is a private function, not part of the 
public 
API part of your object.  And under most circumstances, I would completely 
understand why.  But I'm asking you to consider an exception, as doing so will 
allow 
me (and anyone else who wants to use your library like this, which I am sure 
there 
are others) to work around the bug.  

This satisfies your goal, in that you don't have to do any testing or 
development on 
your library to fix the bug that I found... and it accomplishes my goal, which 
is to 
have a way to use your library in its publicly downloadable format with a 
workaround 
for dynamically adding it to a webpage.

My workaround simply added that callback to the public API of your object (the 
return statement near the end) with 
"callDomLoadFunctions:callDomLoadFunctions," (in 
the same way that you created public API callbackss for other private 
functions).

All I asked was that you add those simple 42 characters to your code, so that I 
could use the current version, as well as future versions, of your code and 
still be 
able to work around my problem.  It doesn't change any of the functionality of 
your 
existing core code, but makes it so that I can use a workaround and still use 
your 
library.

And I'm asking it here rather than in some other discussion forum because I 
feel it 
*is* a bug, even if it's a bug only with a browser, and because I'm reporting a 
possible solution to that bug, and asking you to consider putting it into your 
code.

Otherwise, I'm relegated to having to always use my own hacked version of your 
code, 
which makes future upgrades more painful, and also prevents anyone else from 
ever 
being able to solve this problem (unless of course they deconstruct your code 
and 
find the same solution I did).

Is it really so unreasonable to ask you to enable me (and others) to workaround 
this 
problems with the "extreme/irregular" uses of it, especially since I did all 
the 
work to find out that all I need is to be able to call one private function 
manually?

Original comment by get...@gmail.com on 22 Jan 2008 at 8:10

[GoogleCodeExporter]

Your issue report is considered INVALID (as of comment 1).

There are NO open points in this discussion and we will NOT discuss the 
validity of
the issue any further (as of comment 6).

Original comment by bobbyvandersluis on 23 Jan 2008 at 10:58

[GoogleCodeExporter]

Hi Getify

My developer is out of town for a while and I'm having a problem getting 
SWFObject to
work with my content.
I've been reading through posts and although I only understand about 50% of 
what you
guys are discussing, I'm wondering if it's not the same problem I'm 
experiencing.
Please have a look at this test page:
http://virtualafrica.co.za/embed-spin-testing/
It works fine in all other browsers, but nothing shows in IE7.

You help will be appreciated.

Original comment by tinusler...@gmail.com on 5 Jul 2009 at 2:19