Skip to content
This repository has been archived by the owner on Mar 3, 2020. It is now read-only.

javascript code inside rails view not running #884

Open
ristovskiv opened this issue Mar 2, 2016 · 12 comments
Open

javascript code inside rails view not running #884

ristovskiv opened this issue Mar 2, 2016 · 12 comments

Comments

@ristovskiv
Copy link

I have a javascript code in a rails view which runs depending on the URI of the page. For example if it has a fragment in the URI it changes it to query string.

if(window.location.hash)
    window.location.href = window.location.href.replace(/#/, '?fragment=')

I need this in order to do something with the fragments on the server side. But it appears that capybara-webkit is not running this javascript, cause when I check the current_url is not displaying the expected behavior. For example i have a request /login#users then i convert that to '/login?return_to=users'. This works with selenium though

@jferris
Copy link
Member

jferris commented Mar 3, 2016

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?

@ristovskiv
Copy link
Author

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

@jferris
Copy link
Member

jferris commented Mar 7, 2016

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.

@ristovskiv
Copy link
Author

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.

@jferris
Copy link
Member

jferris commented Mar 8, 2016

Alright, thanks for the update.

@ristovskiv
Copy link
Author

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.

@thoughtbot thoughtbot deleted a comment from ristovskiv Oct 18, 2017
@twalpole
Copy link
Collaborator

twalpole commented Nov 9, 2017

@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

@ristovskiv
Copy link
Author

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

@twalpole
Copy link
Collaborator

twalpole commented Nov 9, 2017

@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/)

@twalpole
Copy link
Collaborator

twalpole commented Nov 9, 2017

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

@twalpole
Copy link
Collaborator

twalpole commented Nov 9, 2017

@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?

@mhoran
Copy link
Collaborator

mhoran commented Nov 9, 2017

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants