Hi, It seems I am facing the exactly same problem. I also use nsIWebProgressListener::OnStateChange and nsIWebNavigation::LoadURI() to renderer the page and dump into a ppm file. In my OnStateChange, there's a mLoadCount, which adds 1 when a STATE_IS_DOCUMENT&STATE_START comes, and minus 1 when a STATE_IS_DOCUMENT&STATE_STOP comes. Then if the mLoadCount==0, it means the page has been loaded completely. After that, I get docshell from nsIWebProcess, and then presShell. The next actions are as following snippet. render the page in memory. <snippet> nsRefPtr<gfxASurface> surface = gfxPlatform::GetPlatform()->CreateOffscreenSurface(gfxIntSize(width, height), gfxASurface::ImageFormatARGB32); NS_ENSURE_TRUE(surface, NS_ERROR_OUT_OF_MEMORY); nsRefPtr<gfxContext> context = new gfxContext(surface); NS_ENSURE_TRUE(context, NS_ERROR_OUT_OF_MEMORY); rv = presShell->RenderDocument(r, PR_FALSE, PR_TRUE, NS_RGB(255, 255, 255), context); </snippet>
My question is that, I can't render the pages with iframes correctly. It seems the result is just one of the sub-frameset but the main frame. Does the docshell/presShell I get from nsIWebProgress not the one of main frame? (I mean each sub frame can create one aProgress, right?) If thus, How can I get the correct presShell? Thanks in advance! Havvy Babele Dunnit 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_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 > [email protected] > https://lists.mozilla.org/listinfo/dev-embedding > > -- View this message in context: http://www.nabble.com/Flash-plugin-and-OnStateChange-flags-tp23978733p24203787.html Sent from the Mozilla - Embedding mailing list archive at Nabble.com. _______________________________________________ dev-embedding mailing list [email protected] https://lists.mozilla.org/listinfo/dev-embedding
