Hi there, I’m building a site that has a ‘book’ interface to it. Each page is dynamically loaded as the user clicks next and the text on the page is loaded through an XML file.
Everything works great in IE - but it doesn’t operate very well in Firefox. I’ve gone though many posts on various forums and found other people with the same problems mostly with XML photo slideshows.
Has anyone here come up with a fix for this? Seems that anything with complex XML and subfolders seems to wreak havok with Flash player in FF.
hey ontariobill,
I haven’t seen this documented but stumbled across the bug right now.
It appears that the “loaded” property of the xml is triggered with a huge delay in firefox, the internal xml parsing seems to take ages. The only workaround I’ve found is to check for the bytes loaded and total (provided that proper headers are sent) and to double check the loaded property. Hence if you’re loading a xml file, you can compute the %loaded and trick flash by changing the actual computed value to some non zero value (eg 10%) while the loaded property is not set to true. This way a preloader might seem to be stuck for a while : that’s the time it takes to parse the xml in firefox - huge time while the parsing occurs almost immediately in IE.
fact is that this problem may well stay unnoticeable depending on how you handle xml loading, in many cases you will only rely on the onLoad event - moreover it may depend on many parameters (processor, ff version, flash player version, available memory, ff extension, etc…) so there is a possibility that you never encountered it.
So to sum up, the bug as it happens here is as follow :
loading a dynamic xml file (all headers set, content type and size), correct values are returned by getBytesTotal and getBytesLoaded methods, but although the onLoad is triggered nearly immediately after getBytesLoaded >= getBytesTotal in the IDE and in IE, in FF, several seconds occur before onLoad is triggered and loaded is set to true.
I should try to test onData but I can’t afford the time to test and I’m convinced that it would be delayed too. And anyway I found some kind of workaround.
Once again it might be a configuration problem, either on the client or server side, and as I type I’m considering the option of checking if the data is sent compressed from the server to FF, that might explain the little delai, so I might add a header to the client request specifying that it doesn’t accept gzipped reply.
If I get the chance to check it I’ll let you know.
also sorry about plonking a several monthes old thread but I stumbled upon it while googlevestigating for an explanation - and as I happen to have a very old account on kirupa I thought it might be of some interest to someone, although I haven’t been posting on bulletin board for years.
this conversation was not useless at all, here is the explanation :
I was using on the php side
ob_start('ob_gzhandler');
as a (bad ?) habit.
which send compressed data if the request specify it.
We are not supposed to change the accept encoding values in the headers sent from flash, and it appears that the player in FF sends an Accept-encoding : compressed,gzip header.
Replacing
ob_start('ob_gzhandler');
by
ob_start();
resolved the problem, so as I suspected the compression did add the extra time between total loading and onLoad trigerring.
Thanks for you intervention Anogar, did you not reply I may not have investigated further.
as a side note, I might add that this should be considerered as a bug since, as stated in http://livedocs.adobe.com/flash/9.0/main/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00001778.html
Accept-encoding cannot be used in addRequestHeader method, so the behaviour should be consistent from a browser to another, and it appears it is not. As you can’t always control what happens on the server side from a flash development point of view, this may be a serious problem (ob_gzhandler don’t send compressed data if the request didn’t mention the Accept-encoding:compressed directive).
