IE issues with 1.3.1 (slow-down/crashes)

While running Fancybox with D6 we were seeing IE 7/8 either block for a while and/or crash. I've ended up disabling Fancybox in the interim until I can track down the issue. I'm theorizing it has to do with these alpha filters. I'm curious to see if anyone else has seen this.

I can also experience slowdowns using IE8, will try to do some debugging

OMG! I was going crazy over what might be causing this. Thank you for the heads up rwohleb!...

My site's pages were loading fine in firefox (though a bit slow), but in IE8 after the page seemed to have loaded 100%, it would then freeze for 2-3 seconds. Disabling & uninstalling latest D6 dev made pages load in a snap in again (both browsers)!

Let me know if/how I can help in troubleshooting this one.

...this is the latest (today's) reply from the Fancybox forum jsm174 mentions in #1:

Since IE filters use page as a reference in SRC and the plugin/file
(in WordPress & Drupal) can be in different folders, we need to
extract base url from the CSS file (jquery.fancybox-1.3.1.css). A bit
tricky, but IE behavior solves this problem.

Example:

#fancybox-loading.fancybox-ie div {
    background: transparent;
    behavior:
expression(this.runtimeStyle.filter?'':this.runtimeStyle.filter="progid:DXImageTransform.Microsoft.AlphaImageLoader(src='"+
(function(){var t=document.getElementsByTagName('link');for(var
i=0;i<t.length;i++){var h=t[i].href.split('?')[0];if(h&&/
jquery.fancybox-1.3.1\\.css$/.test(h)){return
h.replace('jquery.fancybox-1.3.1.css','');}} return '';})() +"../
images/fancybox/fancy_loading.png',sizingMethod='scale')");

}

It will loop all link tags until it finds jquery.fancybox-1.3.1.css
and ignores '?foo=bar' from that css file and then returns the proper
path to that css file. In my example I'm keeping my css files in css -
folder and all the images in images/fancybox -folder.

Hope this helps to solve WordPress & Drupal problems.

-Jani

hope it helps

This is too ugly to implement IMHO :)

I would rather like to bundle modified jquery.fancybox-1.3.1.css with this module.

Since Fancybox is licensed under GPL, and since we need exact version (1.3+) with slightly modified CSS maybe it would be better to bundle entire fancybox with the module. That would make the installation and upgrades easier.

More info about 3rd party libraries in Drupal CVS: http://drupal.org/node/422996

@bas.hr: I am sure you must have your reasons, but talking about easy upgrading... Lately there is a turn in using Libraries API for that precise reason. Bundling our own version of Fancybox is a step towards the other direction.

How about simply trying to override the css? ...I mean if that is possible at all. I couldn't possibly know... just thinking.

btw it is IE8 I am having issues with. Also rwohleb in #2 is mentioning both IE7 and IE8. So, generalizing title...

Unfortunately Libraries API doesn't help much since there is no working code available at the moment. But you made a good point! :)

There is a jQuery Plugin Handler (JQP) module I'm taking a look at.

skilip gave me a good advice to dynamically generate CSS that will fix the path problem, stay tuned ;)

I am staying tuned!

... as for the Library API vs. jQP, I use both in my setups. I meant to emphasize on the the use of ../sites/all/libraries directory and not one of these modules specifically. But I am sure you got that in the first place ;)

Thank you for stepping up for this task! In the meantime... let me know if I can help by beta-testing.

Subscribing and willing to test. ;)

@bas.hr: In the meantime, I disabled the module to stop people from complaining. I do need fancybox functionality though :(

So, I need to ask... is there a way that I can implement a css fix like the example code from #5 till you have something ready?

... or perhaps I should be keeping my pants on? ;)

Well its a devel version, generally not recommended for production.

To apply the fix, just edit jquery.fancybox-1.3.1.css and set AlphaImageLoader's src to full image path, like described in issue post.

Stupid me... I was so much in a hurry to fix this, that I was looking for css files to apply this in the module's folder instead of the jQuery library's. Thanks and sorry for bothering you with such trivial things.

As for the dev version warning... thanx, I know, but I use dev builds wherever possible. I do this intentionally because I need latest patches applied (lazy me). This means fixes to latest issues + new features I can beta-test. I get functionality and the community gets feedback.

PS: I always backup things!

Well, it's been quite some time now and it seems that no solid solution has been found for this issue in the Fancybox forums. There have been a few suggestions and some success stories on various setups, but no action after July. It seems that using absolute paths for any .png in the jquery.fancybox-1.3.1.css file fixes the issue. The last post mentions a jQuery fix that dynamically changes the PNG paths to the current host at runtime. Since not everyone has a google account, I thought I'd post that code here for everyone to see:

Here is a little jQuery fix a colleague and I whipped up. It will
dynamically change the PNG path to the current host at runtime. You
may need to change the value of "needle" for your setup.

// UTILITY FUNCTION
function getFullHost() {
    var full = window.location.toString();
    return full.substring(0, full.lastIndexOf("/"));

}

// FIX
$document.ready(function(){

     // IE CLOSE PNG PATH FIX
    var needle = "/js/fancybox/fancy_close.png";
    var curFilter = $(".fancybox-ie #fancybox-close").css("filter");

    //console.log("BEFORE: " + $(".fancybox-ie #fancybox-
close").css("filter"));
    $(".fancybox-ie #fancybox-close").css("filter",
curFilter.replace(needle, getFullHost() + needle));
    //console.log("AFTER: " + $(".fancybox-ie #fancybox-
close").css("filter"));

Since there are thoughts of using 1.3.1 instead of the latest 1.3.2 version that seems to be quite buggy (#952668: Future upgrades, buggy Fancybox v.1.3.2), I thought it's time we gave this issue some love ;)

...btw, I've created an issue of its own for the #958774: Support Libraries API (use ../site/all/libraries to store external libraries) I've proposed in #7 and #11.

Am sure writing some PHP code to replace the URLs within the Fancybox CSS file in sites/all/libraries shouldnt be tough, is it?

How about:

1. provide a new tab for it in the admin pages, with a detection message (Fancybox libraries detected in sites/all/libraries) or ask for a path to it (relative to $base_url)
2. provide a button which would fix the fancybox.css IE URLs to absolute paths.

Ofcourse this updating needs to be done again if the $base_url changes, but for most of us, it'll only be a one-time perma-fix.