Woot! It seems nsIWebBrowserListener::OnLocationChange() is my friend...
On 11 Giu, 12:16, Babele Dunnit <[email protected]> wrote: > 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_... > [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 [email protected] https://lists.mozilla.org/listinfo/dev-embedding
