Reputation: 303
I have a problem with capturing screenshot in my local machine. I use FF and IE10 and for FF everything works fine, the screenshots get captured with full size of window. For IE10 I get half of the lower part of the page black and it seems that it is related to scrolling, whenever there is scroll in the page the black bar is seen, otherwise not. I suspect a timing issue, that it might take longer time for IE to capture the whole page.
I have the following code for capturing:
public static void takeScreenshot(String filename)
{
WebDriver augmentedDriver = new Augmenter().augment(AbstractTest.driver);
File screenshotFile=((TakesScreenshot)augmentedDriver).getScreenshotAs(OutputType.FILE);
try
{
FileUtils.copyFile(screenshotFile, new File(getScreenshotsDir() + filename));
}
catch (IOException e)
{
System.out.println("Cannot capture sreenshot." + e.getMessage());
}
}
It seems that I have the exact same problem as stated here: http://selenium.10932.n7.nabble.com/TakeScreenshot-from-Augmenter-RemoteWebdriver-gets-window-only-for-IE-10-others-get-entire-page-td18063.html
Upvotes: 0
Views: 1508
Reputation: 353
i had the same problem for a long long time with IE ( ff and chrome are just fine) a few days ago i just started a remote desktop connection from my hub machine to my node machine and ....magic, everything looks just fine right now :-)
what do you think?
Upvotes: -1
Reputation: 27496
You haven't said which version of IEDriverServer.exe you're using, but I'm going to use my psychic debugging powers to guess that you're using the 32-bit version of the executable running on a 64-bit version of Windows. What you're running into is a known issue with IE 10 or higher, if you're using the 32-bit version of IEDriverServer.exe. The issue is fully documented in issue #5876 in the Selenium project issue tracker. The operative information from a comment in that issue report:
When you are running IE 10 or higher on a 64-bit version of Windows, by default the process which hosts the containing window that includes the browser chrome (address bar, navigation buttons, menus, etc.) is a 64-bit process. The process which hosts the window where content is actually rendered (within each tab) is a 32-bit process.
By default, the IE driver must use a windows hook on the top-level window to allow the browser to resize large enough to display the entire page canvas. This is where the problem is. The windows hook is not installed, because a 64-bit process (the top-level window process) can't execute 32-bit code (the windows hook code in the 32-bit IEDriverServer.exe). The only way to properly fix this will be to create a second (64-bit) executable to perform the window resize.
Unfortunately, any attempts to fix this issue would involve a massive rearchitecture of the IE driver itself, and so there is no timeline for a fix.
As a side note, it's tempting to say "use the 64-bit IEDriverServer.exe for 64-bit operating systems," but that has issues of its own. The same problem (32-bit executables cannot execute 64-bit code and vice versa) happens for sendKeys
, except in reverse. Using sendKeys
also requires a windows hook, but hooks into the client rendering process, which is usually a 32-bit process even for 64-bit IE. Thus, for the 64-bit IE driver, it's hook doesn't get installed into the 32-bit process and sendKeys
takes an extraordinary amount of time to work, on the order of 5 seconds for every key stroke.
Upvotes: 0
Reputation: 840
DOM loading for FF is much more faster that IE. For IE, wait till the document gets in ready state using JS.
do
{
// sleep for few milliseconds.
} while ((string)ie.ExecuteScript("return document.readyState") != "complete");
(Coded using C# - Pseudo code, not complied)
Upvotes: 0