getting "capture_screenshot takes exactly 2 arguments (1 given)" error

[GoogleCodeExporter]

We subclass SeleniumLibrary to add some unique features, and once I upgraded to 
version 2.5 or 2.6 of the selenium library I started getting the 
capture_screenshot error mentioned in the summary.

Part of the problem seems to be that both selenium.py and screenshot.py in the 
SeleniumLibrary implementation has a 'def capture_screenshot', one with an 
optional second arg and one with a required second arg. For reasons I don't yet 
understand, my subclass appears to be inheriting the wrong one. 

Is it a bug that capture_screenshot is implemented in two places? 

Original issue reported on code.google.com by bryan.oa...@gmail.com on 14 Feb 2011 at 9:07

[GoogleCodeExporter]

It's pretty impossible to know what goes wrong without knowing where error 
occurs and seeing the traceback. Having an example to try out would help 
debugging even more.

My guess is that this is somehow related to the metaclass used to register the 
keyword to run on failure. Having capture_screenshot method in two places, when 
the other one helper module, shouldn't have anything to do with this.

Bryan, since you set yourself as an owner of this issue it looks like you would 
do something to it.

Original comment by pekka.klarck on 15 Feb 2011 at 2:51

• Changed state: Pending

[GoogleCodeExporter]

I think you missed the point.

There are two implementations of capture_screenshot, which looks like a bug to 
me. One requires two arguments, one requires one argument and has a second 
optional argument. Shouldn't there be only one implementation of 
capture_screenshot, and if so, which is the right one?

Original comment by bryan.oa...@gmail.com on 15 Feb 2011 at 3:42

[GoogleCodeExporter]

No, I don't think I missed the point.

Yes, there are two different methods named capture_screenshot in the code base. 
This should not matter because only the one in screenshot.py ends up being a 
method of SeleniumLibrary itself via multi-inheritance. The one in selenium.py 
is part of the Selenium API that is used by various keywords but not directly 
inherited. If you don't believe my words, you may believe the code:

>>> from SeleniumLibrary import SeleniumLibrary as SL
>>> for cls in (SL,) + SL.__bases__:
...     print cls.__name__,
...     print 'YES' if 'capture_screenshot' in cls.__dict__ else 'no'
... 
SeleniumLibrary no
Browser no
Page no
Button no
Click no
JavaScript no
Mouse no
Select no
Element no
Screenshot YES
Table no
TextField no
Flex no

I'm sorry for not being more explicit about this in my first comment, but I 
though you knew how the library was organized.

Original comment by pekka.klarck on 15 Feb 2011 at 11:21

[GoogleCodeExporter]

Were you able to figure out what went wrong? Is there anything that should be 
fixed in the library?

Original comment by pekka.klarck on 22 Feb 2011 at 5:14

[GoogleCodeExporter]

No, I haven't been able to figure out the specific problem, though it appears 
to be related to how we are subclassing SeleniumLibrary. 

I think we can close this. 

Original comment by bryan.oa...@gmail.com on 22 Feb 2011 at 6:52

[GoogleCodeExporter]

Ok, closing. I'm pretty sure the problem is somehow related to the metaclass 
that implements the run_on_failure functionality that was added in version 2.5. 
Instead of subclassing, you might want to consider extending the library using 
BuiltIn.get_library_instance:
http://robotframework.googlecode.com/svn/tags/robotframework-2.5.6/doc/userguide
/RobotFrameworkUserGuide.html#getting-active-library-instance-from-robot-framewo
rk

Original comment by pekka.klarck on 22 Feb 2011 at 7:46

• Changed state: WontFix