Closed GoogleCodeExporter closed 9 years ago
This is not a bug -- SWFObject cannot detect FlashBlock and other SWF-blocking
utilities; SWFObject merely detects whether Flash Player is available. If found
(and if correct version), the <object> element is generated.
An add-on like FlashBlock or AdBlock scans the page for <object> and/or <embed>
elements and replaces them with custom content, such as gray boxes. I believe
this happens *after* SWFObject has attempted to perform embeds, so there's
nothing we can do about it.
In short, SWFObject is completely at the mercy of browser add-ons like
FlashBlock and AdBlock.
Original comment by platelu...@gmail.com
on 28 Sep 2010 at 3:59
[deleted comment]
Why not use some kind of bootstrap?
First have swfobject insert a small flash that when it is run changes something
that can be checked by javascript.
Then:
If its set; flash is installed and not blocked, and can be used.
If its not set; don't bother with flash on that page.
Or am i missing something?
Can this not be done for some reason?
Original comment by MatsXSve...@gmail.com
on 11 Oct 2011 at 8:58
@comment #3
Yes you are missing something. Re-read comment #2 as to why this is not
possible...
Original comment by aran.rhee@gmail.com
on 11 Oct 2011 at 3:35
[deleted comment]
I have read that comment.
I don't see any real reason why SWFObject cant work together with
flash-blocking.
In fact i don't see what the point is to invent a new way to include flash if
it cant do this thing right.
Here you have a very clear message from the user that flash is NOT wanted, why
not try to detect that and respect it?
And why not work WITH the people who build the flash-block software?
After all, flash-block addons etc would not be needed at all if the method to
add flash wasn't broken in the first place.
Or is this software really just supposed to be a way to replace one broken
method to include flash with an nicer broken method to include flash?
That would be like polishing a turd.
Original comment by MatsXSve...@gmail.com
on 20 Oct 2011 at 11:00
Your concern is understandable, but I think you're barking up the wrong tree.
1. Flash blockers often selectively block SWFs depending on origin, such as a
well-known advertising domain being blocked, but a SWF from a person's blog
being allowed.
2. If SWFObject were to glean instructions from the blocking software,
SWFObject would need to wait for the software to make the information
available, which slows page load time considerably.
3. If SWFObject were to glean instructions from the blocking software, the
blocking software would need to provide a public API SWFObject can check before
embedding.
4. This API would need to be standardized across the industry or else SWFObject
would need to contain many conditional statements and checks, which goes
against our mission to provide a streamlined library.
5. Anything SWFObject can do (such as checking a public API) you can do
yourself via JavaScript, too. We aren't preventing developers from making those
kinds of choices.
Original comment by platelu...@gmail.com
on 20 Oct 2011 at 4:31
Ok, thanks.
Too bad, i guess ill just have to keep my strict no-flash policy in my designs.
Hopefully problems like this will kill it faster anyway.
Original comment by MatsXSve...@gmail.com
on 20 Oct 2011 at 6:16
Original issue reported on code.google.com by
salmiak...@gmail.com
on 28 Sep 2010 at 2:55