Skip to content
This repository has been archived by the owner on Nov 9, 2017. It is now read-only.

browser back button #50

Open
sandrodz opened this issue May 6, 2015 · 12 comments
Open

browser back button #50

sandrodz opened this issue May 6, 2015 · 12 comments

Comments

@sandrodz
Copy link

sandrodz commented May 6, 2015

this is a great plugin, it fixed most of my issues but 1.

When you use browser back button no events are fired.

@amnesia7
Copy link

amnesia7 commented May 6, 2015

Same here. Back button doesn't seem to be firing my $(function(){....]); code as I was expecting it to.

It looks like the issue is caused by the fact that when the back button is used turbolinks only fires:

page:before-unload
page:after-remove
page:change
page:update

but jquery.turbolinks is only listening for:

$.turbo.use('page:load', 'page:fetch');

When a page is first loaded that uses turbolinks it seems to fire:

page:change
page:update

@kossnocorp any suggestions how this could be resolved?

@amnesia7
Copy link

@sandrodz this worked for me turbolinks/turbolinks-classic#533 (comment)

@rstacruz
Copy link
Collaborator

hi folks — maintainer here but haven't checked in in a while. anyone got suggestions for a resolution?

@amnesia7
Copy link

As far as I can tell if you put a js alert in the body on a page, then click a link to another page, then press the back button the browsers that I tested all (except firefox) showed the alert again. This SO question seems to confirm the same thing (http://stackoverflow.com/questions/2638292/after-travelling-back-in-firefox-history-javascript-wont-run).
Since the majority of browsers run the javascript when you press the back button does that mean that this plugin should run it as well.
Rather than using page:fetch and page:load should it use either page:before-unload or page:after-remove (depending on turbolinks/turbolinks-classic#536) and then page:change since these are fired for both fresh and cached page loads?
I suppose it also depends on the use of data-turbolinks-eval by turbolinks because that might be required to run normal standalone javascript whereas this plugin would only re-fire the jquery-bound javascript which could lead to some javascript running and some not since if the js file is loaded at the bottom of the page body then it doesn't actually need to be within $(function(){ to run unless you need all assets to have loaded as well.
Maybe @Thibaut could offer a suggestion about how best to proceed with this or whether turbolinks/turbolinks-classic#533 (comment) should actually be the resolution and just needs mentioning in the readme somewhere.

@Thibaut
Copy link

Thibaut commented May 26, 2015

Not sure I fully understand this issue. If you want code to be executed every time the DOM is updated by Turbolinks (e.g. to attach event listeners to new elements), you should bind to the page:change event. Since today we now attach the affected nodes in event.data; see turbolinks/turbolinks-classic#537 (README update coming soon).

The page:load fires only when a particular piece of markup (body or partial replacement) is inserted in the DOM for the first time. It doesn't fire on history back/forward & cache restore. As indicated in the README, this is to let you run non-idempotent JavaScript that changes the markup, which you wouldn't want to run twice on the same elements.

Let me know if this didn't answer your question.

@amnesia7
Copy link

amnesia7 commented Jun 5, 2015

@rstacruz page:change is the one to bind to to run the jquery on every page load (fresh or cached via back button etc) although it would probably need to be mentioned in the readme that it gets called on every load (fresh or cached) so if something needs to only be called once then it would be better in a $(document).on('page:load', call instead of the normal $(function(){.

I'm not sure whether you would be better using page:before-unload or page:after-remove. Does the element still need to be on the page when you turn off the jquery binds or does it not matter if they have already been removed?

@Thibaut
Copy link

Thibaut commented Jun 7, 2015

@amnesia7 looks like I was wrong about page:load / page:change. See turbolinks/turbolinks-classic#551.

@Thibaut
Copy link

Thibaut commented Jun 7, 2015

Sorry, wrong link: turbolinks/turbolinks-classic#551

@amnesia7
Copy link

amnesia7 commented Jun 7, 2015

Thanks @Thibaut, sounds like its best to hold back on making a decision about how jquery.turbolinks should work with back button until turbolinks/turbolinks-classic#551 has been resolved.

@heyogrady
Copy link

@sandrodz this fix by @Thibaut resolved all my back button issues: turbolinks/turbolinks-classic@25f07dd

@amnesia7
Copy link

@sandrodz @rstacruz The plugin is working as expected for me too with js only being run for new page loads and then I'm using page:restore to make it run any particular js if the back button is clicked (cached page is restored).

@jeremylynch
Copy link

jeremylynch commented May 9, 2016

How I solved this problem:

1) Use the master version of turbolinks:

gem 'turbolinks', :git => 'https://github.com/turbolinks/turbolinks-classic'

Why? The latest version released was 2.5.3, which does not include this fix: turbolinks/turbolinks-classic@25f07dd

2) Use page:restore method

$(window).on('page:restore', function(e) {
  console.log('backspace')
});

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

6 participants