This adds support for the full Capybara 2.3.0 API. There are two known
incompatibilities:
* Selenium supports outerWidth and outerHeight, which we cannot, because we
dont' have an actual OS window.
* Selenium raises errors after interacting with a closed window. We focus the
next available window after closing.
This commit adds the following:
* Implement Driver#close_window
* Implement Driver#current_window_handle
* Implement Driver#maximize_window
* Implement Driver#open_new_window
* Implement Driver#no_such_window_error
* Implement Driver#resize_window_to
* Implement Driver#switch_to_window
* Implement Driver#window_size
* Implement Driver#go_back
* Implement Driver#go_forward
* Support change events when clearing a text input
* Support setting contentEditable elements
* Support window.close() in JavaScript
* Don't return text from hidden elements
* Skip Capybara specs which use outerWidth, outerHeight
* Don't use Qt object ownership to manage windows
Turns Response into a QObject and sets parent to the
command that emits it.
Each Command is also a child of the decorator commands,
Timeout and PageLoading commnds, so that deleting the
top level command will delete all the children.
See discussion in #430.
reuse the existing manager and just clear its headers and cookies.
This avoids repeatedly setting up the SIGNAL/SLOT callback stuff which
is leading to unclosed pipes on Ubuntu, eventually causing "too many
open files" errors in large test suites.
- This changes the format of console message output to use "|" as the
delimiter instead of ":"; ":" is no good for splitting when there are
URLs and error messages in the output
- WebPage tracks all console messages and clears them out on reset
specs pass with these changes (e.g. mainFrame() => currentFrame() and the new
injectJavascriptHelpers() code in WebPage.cpp).
It seems like the current JS+xpath implementation dives in to iframes already.
Is this desired behavior? I wonder if that works with x-domain iframes? I
doubt it...
Also, this design assumes that we only step one frame down at a time...
Lastly, I'm really not sure how QWebKit decides which frame is currentFrame().
For now, I'm hoping to be able to use the QWebFrame setFocus() method. This
may be a dead end though. We may have to have WebPage manually keep track of
the "current" frame.