sIFR 2.0.5 Compatibility Release
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.
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!
John Faulds | 17 December 2007, 03:48 | link
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
webdev | 10 January 2008, 11:06 | link
Can you give a link?
Mark Wubben | 10 January 2008, 11:21 | 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:
www.designblind.co.uk/sifr/jsoff.jpg 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.
WebDev | 10 January 2008, 15:12 | link
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.
webdev | 10 January 2008, 16:50 | link
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.
Mark Wubben | 10 January 2008, 20:24 | link
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
Jamie | 7 February 2008, 18:57 | link
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.
Mark Wubben | 9 February 2008, 18:58 | link
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 | 7 March 2008, 13:00 | link
Marc, perhaps the new CSS file still contained the decoy styles for the elements in the demo?
Mark Wubben | 7 March 2008, 16:04 | link
Mark, what is the solution to the links now opening new windows? Can that be changed?
Ward | 19 March 2008, 21:54 | link
I haven’t seen that happen, could you post an example in the forum?
Mark Wubben | 20 March 2008, 07:04 | link
Here is the site that is having sifr pop-up problems in the top nav.
http://staging.himss.org/mshug/about/about.aspx
Thanks!
Ward | 20 March 2008, 16:42 | link
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?
Mark Wubben | 23 March 2008, 13:05 | link
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?
Peter | 27 March 2008, 02:39 | link
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.
Mark Wubben | 27 March 2008, 07:05 | link