patch for src

patch for s-core

Opened related issue in S-CORE: SEL-509

A little (somehow nice but also security related) side effect of this new command is the ability to use any browser to get a screenshot from any box src (with this patch) is running on.

Try:
http://<YOUR-SRC-HOST>:<YOUR-SRC-PORT>/selenium-server/driver/?cmd=getScreenshot&1=png

New bugfixed getScreenshot patch to be usable by the java-client-driver

Unfortunately this way getScreenshot will not work for at least the java-client-driver on remote-control side.

I updated the patch for remote-control.

Please remove or ignore the two previous patches:
getScreenshot-SCORE.patch
getScreenshot-SRC.patch

With this new patch the selenium-core patch is obsolete.

This looks great - thanks. Just to note SRC-381 should be closed in favour of SRC-395.

Uploading a patch for getting images of complete pages. You can find a description of it here:
http://browserbeaten.blogspot.com/2008/01/using-selenium-for-getting-full-image.html

Please comment on it.

Hi, guys.

Thanks for you efforts. It is really helpful patch. We need something similar and we are going to use your patch. So I have a couple of questions:

• Does screenshot capturing works with horizontal scrollbars?
• Is it possible to capture SEPARATE ELEMENT. Let me describe briefly why do we need it. I work on a huge project that has a lot of client-side JS. Some component are highly-dynamic and we have a lot of regression bugs with such components. We want to avoid such bugs and I hope that Selenium will help us. One of the solutions would be compare screenshots of these components before and after VCS submits. So we actually don't need full screen shot, just small component. So
  selenium.capureScreenshot(elementLocator) - would be perfect.

And the last question not related to you patch but...

• Why capture screenshot function saves image to file-system. Sometime we don't want to save screenshot we just need to manipulate with it in memory (i.e like compare to sample screenshot).

I think it is better to have API like
Screenshot scr = selenium.capureScreenshot()
scr.save(filename)
scr.compare(new Screenshot(<readPNGimage from fs>))
What do you think?

Hi Anatol,

If you use the patch, you will get the images from the client.

Wrt to getting a separate element, I am working on a separate project to develop a framework for doing asserts like assertNoChange(image, image, ROI), I haven't decided if I will release it as a separate patch or a separate project yet, but I can mail it to you if you are interested.

kind regards,
Tarjei

To Anatol,

The ability to capture only the area around an element sounds like an excellent feature... But I don't think it belongs in something called "screenshot". I think a new command would be more appropriate. I also think than Selenium is in desperate need of namespaces, and I'd be more in favor of something like:

selenium.image.capture.screen()
selenium.image.capture.window(<window-locator>)
selenium.image.capture.area(<rectangle-arg>)

Regardless, capturing a subset of the entire screen is out of scope for this particular JIRA issue.

To Tarjei,
Image comparison also sides like an excellent feature. You could do both, release it as a separate library project and a patch for Selenium. If you make it a library, it'll have a chance to be useful to more projects than just Selenium... just be sure to use the same or more liberal license if you go that route. (Apache2, new BSD, or MIT) are ideal.

To Robert and Tarjei,

Thank you for submitting your patches. Selenium succeeds or fails based on the collaboration between the developers and users of the framework. I really do appreciate the work you have put in here. However, as you point out, Robert, your patch is Java-specific, and I don't want to fracture API capabilities based on client language. (Things are already dicey on the browser side of the fence with different capabilities amongst the supported browsers.) A Selenium RC feature should work for all supported client libraries out of the box. To this end, I'm more a fan of SRC-381 and returning a Base64 encoded string representation of the captured screenshot instead of the raw binary from RC to a Java client. Base64 is cross-language compatible with our target languages of Perl, Python, Ruby, and C#.

Tarjei... your image processing code is awesome. And thank you providing so many test cases! And the results look great! However, I would like this patch reworked as an addition on top of SRC-381, instead of this patch. So, I'm closing this issue (SEL-395) and will create a new issue mentioning that your image merge code should be adapted as a patch to SRC-381. Much of your code will be reused as is, the primary difference between SRC-381 and SRC-395 is the transport mechanism back to the client. Also, note, there is a new command in Core called "captureEntirePageScreenshot" that needs to reconciled in some way to your code. Here's the relevant commit for captureEntirePageScreenshot ( http://svn.openqa.org/fisheye/changelog/selenium?cs=1975&csize=1 )

Cheers,
Jason Huggins

Though a lot of work has gone into the implementation of this patch, I'm closing it in favor of SRC-381. Officially, SRC-395 is considered a duplicate of SRC-381. The implementation behind SRC-381 is cross-language out-of-the box, transferring the image back to the client as a Base64 encoded string, instead of a raw Java-specific BufferedImage binary.