New issue 3536 by totzi...@gmail.com: Capture Screenshot keyword captures
black screen for IE
http://code.google.com/p/selenium/issues/detail?id=3536
I have 3 virtual machines with various versions of IE. All of the
screenshots captured are black screens regardless whether the virtual
machines and the host are locked or not. The test automation is triggered
from Hudson.
When I manually tested Capture Screenshot keyword using IE, it seemed to be
fine. However after I left the virtual machines over the weekend for test
execution, the problem started. Rebooting the virtual machines and the host
did not help.
I don't see anything abnormal in selenium log.
Virtual Machine 1
------------------
Selenium version:
2.8.1 package but replace selenium-server.jar with 2.20.0
Robot Framework version:
2.6.3
OS:
Windows XP SP3
Browser:
Internet Explorer 7
Virtual Machine 2
------------------
Selenium version:
2.8.1 package but replace selenium-server.jar with 2.20.0
Robot Framework version:
2.6.3
OS:
Windows XP SP3
Browser:
Internet Explorer 8
Virtual Machine 3
------------------
Selenium version:
2.8.1 package but replace selenium-server.jar with 2.20.0
Robot Framework version:
2.6.3
OS:
Windows 7 Ultimate SP1 (32 bit)
Browser:
Internet Explorer 9
Issue 3561 has been merged into this issue.
Have you tried leaving a VNC server running on every virtual machine?
We had this issue where Windows would sometimes cause black screens because
the machine/desktop was not in use. Running a VNC service on those machines
fixed that problem for us.
Thanks for the suggestion. Our test automation job is triggered remotely
from Hudson actually. With VNC, I have no idea how we can accomplish the
tasks done in Hudson (i.e. check out newly updated files, display the
results in Hudson job, multiple Hudson jobs dependency, etc)
Found a workaround utilising the idea of VNC server. Instead of using VNC
server, I remove the Hudson windows service at the slave node. I create a
batch file using command mode to establish the connection to Hudson.
Content of the sample batch file (assume it's called test.bat) is as
follows. c:\my-slave\ is the location of slave.jar.
cd c:\my-slave\
"C:\Program Files"\Java\jre6\bin\java -jar slave.jar -jnlpUrl
http://myhudson.com:8080/computer/my_machine_99/slave-agent.jnlp
Place the newly created batch file, test.bat, into the Windows Startup
directory to launch the batch file each time it's logon.
With this solution, I don't get black screenshot anymore.
By the way, the Robot Framework command used is "Capture Screenshot" (not
Capture Page Screenshot). Ideally, Capture Page Screenshot is preferred
because the entire page can be captured but it does not seem to be able to
work at all for Internet Explorer.
We've found that the first screenshot taken with a driver often is all
black, but subsequent ones will not be; try taking the screenshot again
The black screen capturing issue I encountered was always black screen
being captured regardless how many times I run the robot framework script.
I didn't try capturing the same screen more than once within the same
script though. That could be a potential workaround too.
Anyway, it has been overcome by my workaround above utilising a batch file
to establish connection to Hudson instead of using windows service.
Thanks for the suggestion anyway as it has given me more workaround ideas.
I have the same problem and I've tried the VNC workaround, but it didn't
work for me. Could you please post your VNC version and settings?
I finally managed to get a workaround for this issue.
In my case, the problem was that I connected to my test servers with Remote
Desktop, which locks the computer after disconnect (I haven't found any way
to change this behaviour). If the test computer is locked, IE screenshots
go black.
So I've created a disconnect.bat file with this line:
tscon rdp-tcp#0 /dest:console
Instead of disconnecting from remote desktop, I run disconnect.bat and my
test computer doesn't get locked. Now I have real screenshots :)
I have to credit Nepatsfan from:
http://forum.soft32.com/windows/stop-Remote-Desktop-locking-host-ftopict360189.html
for give me a hint on this.