Xvfb + firefox: how to know firefox finishes rendering?

I'm trying to grab web thumbnails by using X server to run Firefox in headless (Xvfb) X11.

I am looking for a way to know when Firefox FINIS开发者_如何学编程HED rendering and then I can use image programs to grab the windows.

Problem: I can NOT determine when Firefox finishes rendering. All I know is that the status bar should have an output of "Done" once it finishes rendering (IE, as shown in Firefox in GUI).

Can anyone know what can I use to determine whether if Firefox finishes rendering a page or not?

What I did is just sleep 40 seconds but this may not always work.

Environment: Centos 5.7, Xvfb, Firefox 3.6.23

Shell commands:

Xvfb: 1 -screen 0 1024x768x24 &

export DISPLAY=localhost:1.0

DISPLAY=localhost:1.0 firefox http://www.example.com -width 1024 -height 768

sleep 40  **[ NEED some thing to tell me if Firefox finishes rendering ]**

DISPLAY=localhost:1.0 import -window root example.com.png

pkill firefox

Three methods off the top of my head.

1. Write your own extension that hooks to window.onload and fires the image grabber.
2. Write a greasemonkey script that hooks to window.onload and fires an alert. Wait for such alert, then run your image grabber.
3. Periodically grab the image of the Stop button (should be at known coordinates relative to the window) and analyze its color. If it's disabled, the rendering is finished.

Note that I don't think this can be done with FF 4.x and above easily. This is due to "features" of these versions. My recommendation to you is to use some different browser if you can, like Opera. I did not test it myself yet, but I think it does not have all those flaws noticed with FF. See below.

In your case following solution may be efficient:

Write some Greasemonkey script which adds an absolute positioned rectangle somewhere on the screen.

Let this rectangle flash in a 3 cycle when the page has finished loading: red, blue, transparent

Write a script which waits at least 2 such cycles to complete (so it sees red, blue, something, red, blue) and then do a screenshot with the correct timing in the transparent phase.

This should be doable with X11 and VNC and similar. Sorry that I don't have a better solution nor code I can present here.

I for my part would solve it using EasyRFB which I wrote to solve similar things. However I cannot recommend that to you, yet, except if you are very desparate Genius able to read and understand horrible undocumented code fragments with ease ;)

BTW, thanks for noting the idea of a package which is able to screenshot arbitrary web pages, which makes an excellent use case for EasyRFB. Never thought about this myself before.

Looking at GitHub I noticed, that there are some solutions for taking web screenshots based on Selenium or WebKit. These are certainly good for promotional shots, but they apparently cannot cover the general usecase on how users see web pages.

Perhaps it would be interesting to be able to automate screenshots from arbitrary pages as seen by a Windows 95 IE 4, FF 1 or Debian Potato with Chimera etc. I'll have a look into this ;)

Note that there is another posting on Stackoverflow from me.

There is something I call EasyRFB which I wrote in a mix of Python (core), PHP (small web helpers) AJAX and bash (control scripts). It was tested with XVnc but shall work with any VNC. It somehow is able to do what you want, but beware, it is development code, undocumented, complex and horribly written and may be faulty. You can find it there:

• GitHub: https://github.com/hilbix/pyrfb/tree/easyrfb
• My old development directory: http://hydra.geht.net/easyrfb/

It was written for following purposes:

• Being able to control a remote GUI from a Mobile even in a situation where the Internet connection is extremely slow and extremely unreliable
• Complete UI automation / replace mouse by commandline
• Automated QA tests, based on what the user sees in contrast to what the browser or some windows spy program sees, in cases where the output needs not to be pixel-color-perfect as well

It was not written to be fast nor efficient nor easy to use nor for others (yet). It works, for me, somehow.

What it does:

• is Web centric and gives a AJAX Web frontend to VNC servers, somehow.
• keeps a highly compressed .jpg updated to the contents of the screen.
• can take lossless screenshots
• is able to fuzzy-match templates against the contents of the screen
• templates can be Web-edited with edit.html - however this editor is basic, not self-explanatory and not documented at all
• Shell scripts can be written which can wait for these templates to match and send commands like keypresses, mousemoves and clicks to VNC
• There are some .sh scripts which could help to understand how this is done, but I am not able to publish the really helpful stuff yet, sorry

Nothing is documented and I am not able to explain how to use it. Either you find out yourself or you are lost. Sorry. Better don't even look at it, it might hurt you.

And now to the problems noticed with FF while doing all this:

Newer FF versions fail to properly update the screen. The last version known working correctly at my side was the FF 3.6 series, all later sometimes develop some strange behavior.

For example:

• Newer versions now update the status before they update the screen contents.
• Also they have such a high CPU and memory demand, that finishing the last step on updating the screen can take some time. On slow hardware (like the NSLU2, never tested) I think it might even take minutes after the Spinners etc. are already in the "finished" state.

So even looking at the spinner to become gray including(!) naive Greasemonkey solutions which notify about "onload()" both fail with FF 4.x and above, because parts of the screen may still not be updated when you detect that it is ready.

Maybe it has only to do with XVnc, perhaps there is a bug in my scripts which triggers all this, but with FF 3.x everything was right and I think, reverting to an old version would immediately solve all those problems seen. (But I already have workarounds in place for all those trouble. But I cannot publish that scripts, sorry.)

It gets worse.

FF 4.x and above apparently delay event processing a bit. So jumping the mouse out of the scrollbar often keeps it highlighted, I think the event does not reach the scrollbar.

On a normal desktop you do not jump your mouse, but my solution is able to do so. The fix is to generate additional, superfluous mouse movement events to have FF do the right thing.

Also I noticed, I really have no idea if it is due to FF or the web pages shown in FF, that sometimes things do not land where they are supposed to be. I never observed this before with FF 3.x though. The trick which solves this is to reload the page. It might have to do with incremental screen updates, but I did not dive into this yet as the retry (automated clicking on the reload button) works for me.