We have a number of test cases around current_url and window.location, but the behavior there isn't always clear cut. Is there a minimal test case you could put together for the issue you're seeing?

Sorry for the late reply. Sure, I will gladly do it, but can you please give me some instructions on how to do it?

Sure, I will gladly do it, but can you please give me some instructions on how to do it?

Sure!

If you can put together a running example that I have access to, such as a GitHub repo or Gist, I can run it locally and poke at it to try and debug. The fewer moving pieces there are, the easier it will be for me to determine what the issue is.

A popular choice is a single repository with a Sinatra app and a single Capybara test.

Here is the repo url, although funny thing is here with Sinatra it works. But with Rails I wasn't able to do manage this and get something else from the current_url helper. I will setup a scenario with Rails just to make sure that I'm not the one that gives a false issue.

Alright, thanks for the update.

Really sorry for delaying this. I've managed to simulate the fail. Here is the repo. It appears that capybara-webkit doesn't run the script on redirects. If I'm not clear enough you can ping me at any time.

@ristovskiv I am unable to get that repo to run - I get a a stack level too deep error when attempting to migrate the database. If you can fix and update the repo to current gem versions and ensure it works I will take a look ASAP

@twalpole the database is pretty simple, it only has one 1 migration file with 1 table/relation.

@ristovskiv Now that you locked the repo to ruby 2.3.3 it works for me, not sure why it wasn't before.
Looking at the output of this I don't think it has anything to do with capybara-webkit nor running JS, rather the redirect from / doesn't get the previous fragment applied to it, so the request to /user/sign_in doesn't have a fragment for the JS to work with. This was run with the master branch of capybara-webkit.

Started "Visit(http://127.0.0.1:61640/#something)"
Load started
"Visit(http://127.0.0.1:61640/#something)" started page load
Started request to "http://127.0.0.1:61640/#something"
Finished "Visit(http://127.0.0.1:61640/#something)" with response "Success()"
Started request to "http://127.0.0.1:61640/users/sign_in"
Received 302 from "http://127.0.0.1:61640/#something"
Started request to "http://127.0.0.1:61640/assets/application-e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.css"
Started request to "http://127.0.0.1:61640/assets/application-2076ceeb8dca6913905558947e208161252b023ab6c101b318654fdc580fd838.js"
Received 200 from "http://127.0.0.1:61640/users/sign_in"
Received 200 from "http://127.0.0.1:61640/assets/application-e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.css"
Received 200 from "http://127.0.0.1:61640/assets/application-2076ceeb8dca6913905558947e208161252b023ab6c101b318654fdc580fd838.js"
Page finished with true

Additionally, for stability reasons your path expectations should be written more along the lines of

 expect(page).to have_current_path(/fragment=something/)

This would appear to be an issue with QtWebkit, and may just have been the way webkit browsers worked back when the QtWebkit version being used was released - https://www.w3.org/TR/cuap#uri - not sure there's anything capybara-webkit can do about it

@jferris @mhoran I don't know enough about the Qt network handling to quickly figure this out. Do you know whether capybara-webkit is handling redirects itself, or just letting the QtWebkit default behavior happen?

These redirects are handled by QtWebKit itself. We hook in to the network manager in a few places but mostly such behavior is inherited from WebKit.