Hello everybody, in our custom implementation we used the progressStateFlags passed to nsIWebProgressListener::OnStateChange to detect the start and stop of load of the "main page", the one which was requested via nsIWebNavigation::LoadURI(). I know, a lot of things can happen (redirects etc) but, generally speaking, detecting
STATE_START & STATE_IS_DOCUMENT & STATE_IS_NETWORK & STATE_IS_WINDOW & STATE_IS_REQUEST was enough for our job to say, "ok, this is the mother of all loads". I dont know if this changed recently, or its just me which never realized, but I see that a lot of pages with embedded flash movies (i.e. YouTube), after some seconds from the load and in an unpredictable manner, will enter again OnStateChange with same combination of flags and with an URI like http://n4061ad.fr.doubleclick.net/adi/com.ytpwmpu.entertainment/main_1601;sz=300x250;plid=AARsD6bY2Q9EZDdA;kl=N;!c=1601;k2=358;klg=it;kvid=KnXBeVp5cW4;kpu=rai;kr=F;khd=0;kt=K;ko=p;kpid=1601;afc=1; [snip] and this is not good for us, because we do some stuff when a page begins and ends loading (cleaning stuff and parsing the DOM). Also, on page load end I stop the flash plugin, change its wmode forcing "opaque" and restart it, and this makes everything loop forever. Ouch. So: 1) is there a guaranteed and unique combination of OnStateChange flags which means "this is the page you requested"? (answer: to me, it seems "no") 2) which is the best way to deal with this bug? Check for all nsIRequests entering the OnStateChange callback, storing the one matching the URI requested via nsIWebNavigation::LoadURI() and considering that the "mother of all loads"? Could this work? Are the nsIRequest pointers persistant during one load? Any better idea than this brute hack? Thanks in advance, Aaron Brancotti/Babele Dunnit _______________________________________________ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
