Skip to content
This repository has been archived by the owner on Nov 29, 2018. It is now read-only.

Python remote webdriver does not take screenshots #833

Closed
lukeis opened this issue Mar 2, 2016 · 6 comments
Closed

Python remote webdriver does not take screenshots #833

lukeis opened this issue Mar 2, 2016 · 6 comments

Comments

@lukeis
Copy link
Member

lukeis commented Mar 2, 2016

Originally reported on Google Code with ID 833

What steps will reproduce the problem?
driver = selenium.remote.webdriver.WebDriver("http://localhost:4444/wd/hub", "firefox",
"ANY")
driver.get("http://google.com")
driver.get_screenshot_as_file("test.png")

What is the expected output? What do you see instead?
Expected: return value True and saved screenshot test.png

Actual:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/hrubi/.local/lib/python2.6/site-packages/selenium-2.0a5-py2.6.egg/selenium/remote/webdriver.py",
line 321, in get_screenshot_as_file
    f.write(base64.decode(png))
TypeError: decode() takes exactly 2 arguments (1 given)

What version of the product are you using? On what operating system?
remote server run: selenium-server-standalone-2.0a5.jar
python client: selenium-2.0a5.tar.gz from http://pypi.python.org/pypi/selenium/2.0a5

Please provide any additional information below.
http://code.google.com/p/selenium/source/browse/trunk/remote/client/src/py/webdriver.py#325
            f.write(base64.decode(png))
should read
            f.write(base64.decodestring(png))
It works after then.


Reported by hrubi13 on 2010-09-26 12:23:41

@lukeis
Copy link
Member Author

lukeis commented Mar 2, 2016

Attached is a patch that will fix this error, and also delete the png from memory when
finished with it. This way, if you are running this command multiple times, in a test
you will not keep data in memory you are no longer using.

Reported by antlong on 2010-10-07 15:40:55

  • Status changed: Fixed

- _Attachment: [screenshot-as-file-fix.patch](https://storage.googleapis.com/google-code-attachments/selenium/issue-833/comment-1/screenshot-as-file-fix.patch)_

@lukeis
Copy link
Member Author

lukeis commented Mar 2, 2016

That "del png" doesn't actually do anything in most cases, as the png variable is only
bound inside that function, which is about to end.

The one case I can think of in which it may have an effect is if you had an exception
that wasn't an IOError, so a traceback was generated, with the stack, so the stack
kept a reference to "png".  Then, I think, that "finally" clause would kick in and
remove "png" from that stack frame.

Reported by keturn@keturn.net on 2010-10-07 16:31:53

@lukeis
Copy link
Member Author

lukeis commented Mar 2, 2016

Fixed as of r9847

Reported by simonstewart@google.com on 2010-10-07 16:35:11

@lukeis
Copy link
Member Author

lukeis commented Mar 2, 2016

And now marking as fixed :)

Reported by simon.m.stewart on 2010-10-07 16:35:27

@lukeis
Copy link
Member Author

lukeis commented Mar 2, 2016

keturn.keturn: no, once png is assigned, unless the mechanism that takes the screenshot
breaks - some object will always be assigned to 'png'. we catch an io error, but do
not `raise` an exception which would exit the program, and garbage collection would
clear the memory.

since we are returning True / False, we do need to clear png after its finished since
the function was written to not raise errors if the writing of the file should fail.
Also, screenshots can be pretty large depending on many factors, so its a good idea
to remove it as soon as we can determine whether we return true or false.


Reported by antlong on 2010-10-08 00:21:10

@lukeis
Copy link
Member Author

lukeis commented Mar 2, 2016

Reported by luke.semerau on 2015-09-17 17:50:16

  • Labels added: Restrict-AddIssueComment-Commit

@lukeis lukeis closed this as completed Mar 2, 2016
@SeleniumHQ SeleniumHQ locked and limited conversation to collaborators Mar 4, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant