I stand by what I've said. Telling people "hey, use
this function, it seems to fix our problem" is just as much misinformation as
telling someone that if they pick a lock that was meant to be opened with a
specific key, that this is ok because at least it gets the door open. It wasn't
intended to be done that way. You may do so, and I can't stop you, but it is
misinformation to post on this list (which is archived for forever in the
web/search engines) that it's a valid workaround, because it is not. At least in
my opinion.
I also stand by what I've said about the fact that
this problem (the flash mis-rendering issue in FF3.5) is, so far as I know, only
happening to people who are using swfobject incorrectly, according to our best
practices. I have not yet seen a reliable, reproduceable test case where
our standard code-generator generated code/markup fails to work in FF3.5. If
someone can provide such, and I can verify, then I'll re-examine my position.
But until then, so far as I know, they are experiencing unintended behavior
because they are using the library in an unintended way. The behavior in this
circumstance is both undefined and unsupportable (practically
speaking).
Let me clarify again, so everyone understands. The
"switchOffAutoHideShow()" function has one, and only one, purpose. That
is:
1. control whether the alternate content (in the
case of dynamic publishing), OR the swf itself (in the case of static
publishing) is initially hidden during the duration of time (mere miliseconds)
when swfobject has taken control of said content, and is doing version checking
and/or attempting to embed the content.
Once that brief period of time has elapsed, and
SWFObject knows what it's going to do, it always re-shows something, either the
alternate content, or the SWF, depending on success/failure.
Previous to adding that function, authors had no
control over this behavior. We always assumed we should hide those things, to
prevent the said unwanted content from unnecessarily being shown and then hidden
again. For instance, how ugly is it UX wise to go to a page, and see first a JPG
saying "download flash", and then pop in a second later the intended flash.
You'd say to yourself, "man, they shouldn't have shown me that 'get flash'
button since clearly I have flash". So, you'd probably want to just hide that
until a version check could know if the alternate content or swf was appropriate
to show.
But, some people didn't like that UX. Or in some
rare cases, it provided a different kind of styling the considered ugly
UX. They wanted more control. So we gave it to them. We said, OK, we won't
auto-hide anything while we're waiting. We'll let you take care of that yourself
with your own CSS, JS, etc.
Notice how in none of that discussion was there any
notion of "Some people had bugs in FF3.5 so we gave them a hack function to work
around it". That function was not designed for that. Plain and
simple.
In fact, I'd go so far as to say, as an educated
guess, that the site in question would probably perform the same with SWFObject
2.1 as 2.2, as I don't see anything about the situation that should be different
(except that 2.2 has this function which people are trying to use). But as I've
said, that's putting a bandaid over a splinter without removing the
splinter, and expecting it to heal. You haven't solved the problem, you've
masked it.
To further clarify:
SWFObject does not, under any normal circumstances
that I'm aware of, accidentally leave a SWF hidden, in FF3.5 or anywhere else.
So, shutting off SWFObject's behavior to initially hide the SWF (in the static
publishing model) is NOT what's solving your issue. You are simply allowing the
SWF in all cases to show up and effectively disabling SWFObject from working
properly. If it is remaining hidden, so far as I can tell, it's because
something is.... WRONG.... with the authored code or flash. Not a bug in FF or
SWFObject.
Perhaps this is a corrupt flash version install in
the FF3.5 in question. Perhaps the version number is wrong. Perhaps the author
is not properly putting their code in the HEAD of the document. Or any number of
other possible problems.
-------------------------------------
But in no way shape or form do I think (and others
may disagree with me, that's fine), that it is CORRECT information to tell
people "hey, if you have trouble with FF3.5, don't try and fix your code, just
use this function and it'll magically work". I call that misinformation. And I'm
sorry if I've offended people by having that opinion.
I remain open to having someone give me a reliable
test case which disproves what I'm saying. I'll happily troubleshoot. And I'll
personally fix the bug in SWFObject if there is one, or champion the bug report
to Mozilla if there is one. But at this time, I don't have enough reliable
information to say as such.
--Kyle