sIFR 2′s links do not work with the new Flash Player 9,0,115,0 if a hover color is specified. Additionally, no elements are replaced in Safari 3 if the content type of the XHTML document is application/xhtml+xml. This has been resolved in sIFR 2.0.5.
If you’re using sIFR 2.0.3 or older, and have a hover color specified for links, or are using XHTML documents with the proper content type, you are advised to upgrade immediately. You must upgrade the sifr.js JavaScript code and re-export the Flash movies.
If you’re using sIFR 2.0.4, and are using XHTML documents with the proper content type, you are advised to upgrade immediately. You must upgrade the sifr.js JavaScript code and re-export the Flash movies.
sIFR 3 is not affected by the Flash player issue. Revision 341 is no longer affected by the Safari XHTML issue.
sIFR 2.0.6 has been released.
There has been one other change in Flash 9 possibly affecting sIFR users: it will not be possible to use links in a Flash movie loaded from a different domain than the HTML page. I’ve decided not to fix this issue, as the workaround changes the security settings for the sIFR Flash movies. sIFR 3 is not affected by this issue, as it already depends on the workaround.
Detailed Description
In order to support long URLs in Flash 7 and Internet Explorer, when you click on a link in sIFR an ActionScript function is invoked. This function will then cause the browser to follow the link. The anchor element is modified before being passed to the Flash movie to point at asfunction:launchURL,i, where i is an index for the link. Flash 9,0,115,0 still supports clicking on these links, however if a hover color is specified, the link is resolved using an onRelease handler on the parent element of the text field. This handler then tries to follow the link using getURL(). With the new Flash Player it is no longer possible to call an asfunction through getURL(). The code has been modified so that launchURL is called directly.
There’s a serious regression in Safari 3. In XHTML documents the normal properties like document.location, document.cookie and document.body are no longer available. This has been resolved in the WebKit nigthlies, but not in Safari 3.0.4. sIFR 2 had a check for document.body, which I’ve now removed.
See also:
Thanks Mark for sorting this out!
Thanks for the fix – I can now click my links again. However they are all opening as new windows which they didn’t previously … any thoughts? Thanks
Can you give a link?
I’ve actually fixed that issue now by adding a check on the value of ‘launch url target’ before the ‘get URL’ call inside the ‘dont customise me.as’ file (sorry!)
However the upgrade to version 2.0.5 also seems to have stopped my links from wrapping. I’m afraid the site in question is on an internal development server so I can’t give you a link. I don’t know how much use they’ll be but i’ve put a couple of screenshots here:
http://www.designblind.co.uk/sifr/jsoff.jpg http://www.designblind.co.uk/sifr/json.jpg
As you can see, the right amount of vertical space appears to be being allocated but the sifr text isn’t wrapping into it.
FYI: all I did was replace the ‘sifr.js’ & ‘sifr addons.js’ files and re-export my defused swf. Non of the CSS has been changed – which is why I’m so puzzled!
Many thanks in advance for any help you can offer.
Update: I think i’ve found the cause of the issue. In the ‘dont customise me.as’ file there is a while loop that appears to control the text size. The first of its three condition checks is ‘holder.txtF.maxscroll == 1’ – this line fails for my long title as the value of maxscroll in that case is 2. Hence the loop never runs. Hence text comes out at default size (6). So I’ve removed that check. And everything seems to work fine again now.
So now my question is why was that line in there in the first place? What will break as a result of me removing it?
Many thanks.
I haven’t got the slightest idea, Mike Davidson wrote that code. But perhaps you’d be interested in sIFR 3 which has much better font sizing support.
Just wondering about the ‘interference’ of Adblock with the addition of the ‘Adblock’ tab to the flash movies on the page. I see in the css file their is come code which looks to hide these, but it doesn’t seem to work (in my example or on this page as I view it now).
I know I can disable the option, but I’m more worried about other users who come to the page and see these tabs. I see it as a big draw back to actually using this on a live site.
I’m not afraid to say I’m very much a hack when it comes to css and javascript, but I did use the web developer plugin for firefox to show me the element is accessible in the page as it has the following css attribute;
DIV #adblock-frame-n** (where ** is a incremental number for each element it uses on the screen.)
Having just got this machine I’m pretty sure I’m running all the current versions of the software. Firefox 2.0.0.11 Adblock v.5 d3 * nightly43
Hiding the tabs isn’t really an option. There was some talk of adding a “white list these movies” feature to AdBlock, but I don’t think this ever happened. I think that solutions have to come from AdBlock, much like how FlashBlock actually shows browser text rather than the blocked sIFR Flash movie.
There’s a problem with v2.0.5, well at least I have one
When I replace my old sIFR-screen.css (v2.0.1) all my other, non sIFR, headers break – become non visable. Don’t know if it has to do something with it but i’m using the flasytitles plugin for wordpress to manage the sIFR headings.
My workaround is to update all the files (swf, js and even the sIFR-print.css) to v2.0.5 but leave the sIFR-screen.css at v2.0.1.
Marc, perhaps the new CSS file still contained the decoy styles for the elements in the demo?
Mark, what is the solution to the links now opening new windows? Can that be changed?
I haven’t seen that happen, could you post an example in the forum?
Here is the site that is having sifr pop-up problems in the top nav.
http://staging.himss.org/mshug/about/about.aspx
Thanks!
It’s not supposed to do that, and the sIFR 2 version I use to test with doesn’t do it either. No idea what’s up with this, sorry. Perhaps sIFR 3 works better?
sIFR 2.05 works beautifully in Safari, but it fails in FF 2 and IE 7. FF 2 displays only one headline on my test page and blanks out all the rest, and in IE 7 it blanks out all headlines.
Also I notice looking above, that it does not work right on this site either; the bottom fifth of “BERBORN” is blanked out by the background to the words “straight line circle sometime” in IE 7.
Is there another version of sIFR that works?
The header text on this page is not sIFR, and I just didn’t fix it up properly for IE. Could you make a post in the forum for your sIFR 2 issue?
You may want to try sIFR 3 by the way, works much better than v2.
I’ve downloaded the new Flash 10 beta player and sIFR 2.05 doesn’t detect it, tried looking at the source code but couldn’t find anything useful. Should sIFR automatically work with newer Flash versions or is there a limit to versions 6-9?
It should work. I’ll look into it, could very well be an issue with the Flash beta.
Yeah, could be a beta issue. It’s a bit annoying though ‘cause I like the new Flash player, it fixed my problems with Flash videos sometimes hanging after 2 seconds in Firefox. I’ll keep checking back here for a possible resolve.
Mark, when replacing using this code: [dl] [dt][h1]test[/h1][/dt] [dd]Lorum ipsum blabla[/dd] [/dl] The replace H1 is moved AFTER the “dt” which should not happen.
Gilles, could you post in the forum with a link? Thanks!
hi,
i’m using sIFR 3 and i still have a problem with the links in Firefox. they don’t work. any idea what’s wrong?
Flavius, please post your questions to Stack Overflow.