capybara-webkit/src/Reset.cpp

#include "Reset.h"
#include "WebPage.h"

Reset::Reset(WebPage *page, QObject *parent) : Command(page, parent) {
}

void Reset::start(QStringList &arguments) {
  Q_UNUSED(arguments);

  page()->triggerAction(QWebPage::Stop);
  page()->currentFrame()->setHtml("<html><body></body></html>");
  page()->networkAccessManager()->setCookieJar(new QNetworkCookieJar());
  QString response = "";
  emit finished(true, response);
}
Initial commit 2011-02-19 03:53:06 +00:00			`#include "Reset.h"`
			`#include "WebPage.h"`

			`Reset::Reset(WebPage page, QObject parent) : Command(page, parent) {`
			`}`

Refactor Connection/Command so that arguments are passed in as a single QStringList instead of in consecutive calls to argumentReceived 2011-02-26 04:29:36 +00:00			`void Reset::start(QStringList &arguments) {`
			`Q_UNUSED(arguments);`

Initial commit 2011-02-19 03:53:06 +00:00			`page()->triggerAction(QWebPage::Stop);`
Working on frame handling. In terms of the QT code, the non-frame-related 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. 2011-04-19 07:16:25 +00:00			`page()->currentFrame()->setHtml("<html><body></body></html>");`
Fixed cookies not being reset after each session 2011-02-26 22:05:28 +00:00			`page()->networkAccessManager()->setCookieJar(new QNetworkCookieJar());`
Initial commit 2011-02-19 03:53:06 +00:00			`QString response = "";`
			`emit finished(true, response);`
			`}`