You can clone with
HTTPS or Subversion.
<%= link_to "Cancel", :back %> generates a link to the current page
<%= link_to "Cancel", :back %>
Could be fixed by setting referer on fetchReplacement
I tried this:
fetchReplacement = (url) ->
xhr = new XMLHttpRequest
xhr.open 'GET', url, true
xhr.setRequestHeader 'Accept', 'text/html, application/xhtml+xml, application/xml'
xhr.setRequestHeader 'Referer', historyCache[window.history.state.position - 1].url
xhr.onload = -> fullReplacement xhr.responseText, url
xhr.onabort = -> console.log "Aborted turbolink fetch!"
But it doesn't work (on chrome) and gives the warning Refused to set unsafe header "Referer". I don't think it'll possible as setting the referer is disallowed by the XHR spec (see here).
Refused to set unsafe header "Referer"
Ah, so are we going to have to do a custom header var and server side handling to override referrer?
This is actually a history pushstate bug and is already fixed in chromium
May have to wait for that.
Also already fixed in firefox 4 and greater..
perhaps we can add header X-Push-State-Referer to the request, and leave it to the user to implement a server side solution.
Recommend using alias_chain_method for Rack::Request referer method...something like
@env['X_PUSH_STATE_REFERER'] || referer_without_turbolinks
If we are ok with that approach, ill implement later.
personally I almost never use :back, i prefer to be explicit on the redirects. doing it at the rack level would ensure rails treats the request just like any other regular request.
We do have to override redirect_to, checked source it uses
not request.referer to determine back.
Fixed in 46818ee
I think this issue still occurs and I am using turbolinks 1.1.1. Does anyone else have problems with the link_to :back helper generating a link to the current page?
<%= link_to "Back", :back %>
One way to make :back option works, we have to override HTTP_REFERER in request header, however it is blocked by browser.
Another way to make :back option works, we can change _back_url method defined in actionpack/lib/action_view/helpers/url_helper.rb, like this
def _back_url # :nodoc:
referrer = controller.respond_to?(:request) && (controller.request.env["HTTP_X_XHR_RFERER"] || controller.request.env["HTTP_REFERER"])
But this makes the newly potential xss pitfall, since attacker can prepare to send another referrer by setting X-XHR-Referer header.
So in my opinion, to use javascrtip:hisotry.back() you should write it to link_to target path, or hook history.back() on clicking the link.
+1 with @chourobin that link_to back doesn't work on neither v1 nor v1.1.1
+1 @lecky it's funny how we run into the same bug
+1 . @kuboon, thx!
I'm on turbolinks 1.1.1 and still seeing this occur.
Still seeing this happen in Rails 4 rc2 with turbolinks 1.2.0
PR #234 contains a fix
This issue still exists with Rails 4.0.2, Turbolinks 2.2.0. Here's how to reproduce:
$ rails new TurbolinksTest
$ cd TurbolinksTest
$ rails generate controller First
$ rails generate controller Second
$ vi config/routes.rb
get 'second' => 'second#index'
$ vi app/views/first/index.html.erb
<%= link_to 'Second', second_path %>
$ vi app/views/second/index.html.erb
<%= link_to 'Back', :back %>
$ rails s
Load http://localhost:3000, click on "Second" link, once on the 2nd page click on "Back" link. You stay at the 2nd page.
Tested in Firefox 25 and Chrome 32.
Split modules into separate files and fix link_to with :back - Fix #27
Just to close the loop on this, @reed's commit above fixed my issue. Thanks!
@reed It is still not working on Safari 7.0.1.