If I use pushState to change the URL Browser#current_url still returns
the URL as it was after the original request. This commit adds a command
for RequestedUrl, which is the QtWebkit method for retrieving a URL
Seems like the current_url and requested_url behavior would make more sense the other way around.
Completely agree, however it's directly mirroring the QtWebkit API (http://doc.qt.nokia.com/latest/qwebframe.html#requestedUrl-prop). I prefer that transparency over changing the language set in place by the Qt authors.
Although thinking more about it, maybe current_url could become requested_url and we could implement url to return QWebFrame#url (which current_url currently uses). Thoughts?
You left in this merge conflict.
Agh! Thanks for catching that. I'll fix and push today.
Merged your branch without the merge conflict into master.
Perhaps I'm missing something, but doesn't this leave capybara-webkit inconsistent with other Capybara drivers? Personally I have some request specs that assert "current_path.should == blah" that fail with this driver because of the presence of url fragments that do not exist with say the Selenium driver.
I'm not entirely convinced this shouldn't be viewed as some kind of QtWebKit bug, as if you run history.replaceState in other WebKit-based browsers (Safari & Chrome), the URL in the address bar changes, while in QtWeb, which appears to be built with QtWebKit, it does not.
For now I'm going to leave this pull request in, but I'm open to more discussion about these methods and how best to handle them.
I still don't think it makes sense for current_url to return the requested URL and requested_url to return the original URL. The case for following QtWebkit API doesn't make sense to me either, since you don't need to know anything about QtWebkit to use capybara-webkit, it's a Capybara driver.
Edit: I may have confused myself here. Refer to my original comment if I mistyped.
@tristandunn I think this discussion needs to boil down to the actual values these methods should return. For example:
If visiting "/?foo=bar#baz" that contains window.history.pushState('', '', '/qux') what should be the values for current_url,current_path, and requested_url.
window.history.pushState('', '', '/qux')
If I do what selenium is currently doing then current_url and current_path will both end with "/qux"
@halogenandtoast I think the value of current_url is most important.
The current_path method is based on current_url and is implemented in Capybara itself, so it should "just work" if current_url is right.
The requested_url method does not appear to be part of the Capybara API, so I see it as more for internal use to access the corresponding property in QWebFrame.
Simply implementing current_url based on requested_url would do the right thing in the case of pushState/replaceState, but unfortunately it returns the wrong value (original URL) in the case of a redirect.
Here are the values I think current_url should return.
Let me know if you would prefer an example with literal values.