Skip to content
This repository has been archived by the owner on Sep 25, 2021. It is now read-only.

onbeforeunload on back button - prevent user from losing unsaved changes #264

Closed
feliperaul opened this issue Apr 23, 2017 · 15 comments
Closed

Comments

@feliperaul
Copy link

I saw #146 and #216 but still can't find a way to solve a simple requirement: show an alert asking the user to confirm navigating away if he has unsaved changes.

If I bind $(window).on('beforeunload' ..., it will fire when reloading the page, clicking a bookmark or typing a new url in the addressbar, but it won't fire on back button (and also, obviously, won't fire on clicking on internal links).

If I also bind $(document).on('turbolinks:before-visit', function(event) { ... }, this solves the internal links (I can show a confirm alert and use event.preventDefault() to stop navigation if there are unsaved changes), but this also won't fire on browser back button.

The suggestion in #146 suggests binding to $(document).on('turbolinks:before-render', but I can't seem to find a way to show the dialog and cancel navigation if the users clicks cancel, as event.preventDefault() doesn't cancel navigation in turbolinks:before-render

So: how to prevent user from losing unsaved changes when he uses the back button ?

@mttdffy
Copy link

mttdffy commented Jul 10, 2017

+1 Also trying to solve this problem

@timonbandit
Copy link

+1 trying to exit full screen in player on back button instead of navigation to previous page

@tomgong
Copy link

tomgong commented Oct 12, 2017

+1 Having the same problem showing a confirm dialogue before leaving a page via back button.

@maguri
Copy link

maguri commented Dec 11, 2017

Has been this solved?, I have the same issue pressing the back button. 🙁

@timonbandit
Copy link

@maguri drop it :)
I wrote my own realization. it's much more effective and faster.

@maguri
Copy link

maguri commented Dec 11, 2017

@timonbandit ,Where is this "realization"?

@timonbandit
Copy link

@maguri in private repo ;)
It's just an advice.
Could be better to stop searching how to resolve this problem with turbolinks and write your own.

@maguri
Copy link

maguri commented Dec 11, 2017

Yeah sure,
That's what I will have to do at the end!

Thanks @timonbandit 🤙🏼 !

@timonbandit
Copy link

@maguri 👍

@maguri
Copy link

maguri commented Dec 11, 2017

[DEPRECATED] JQuery This has resolved my need: window.onpopstate

@dsmalko
Copy link

dsmalko commented Dec 11, 2017

@maguri How do you cancel navigation?

@dsmalko
Copy link

dsmalko commented Dec 11, 2017

Problem is turbolinks:before-visit isn't fired for back button and window.onpopstate don't prevent turbolinks from navigation.

@leouofa
Copy link

leouofa commented Apr 21, 2018

+1 Having a similar issue. Any ideas?

@andypearson
Copy link

andypearson commented Jul 27, 2018

Just run into this as well.

The docs for turbolinks:before-visit explicitly states "except when navigating by history" so I wonder if there needs to be an additional turbolinks:before-history-change (or similar) event that could be hooked in these cases.

On closer inspection, because popstate is not cancelable, I think this behaviour may be impossible :(

soundasleep added a commit to soundasleep/jquery-modal that referenced this issue Aug 7, 2018
There doesn't seem to be any way to prevent Turbolinks from reloading
and replacing the entire browser window when a user clicks Back (since
turbolinks:before-visit is not triggered for _when navigating by
history_),

So, rather than hiding the displayed modal when clicking Back (and
then having to reload the page), we keep the Modal displayed while
Turbolinks does its stuff in the background (including progress bar).

See turbolinks/turbolinks#264 for a related
issue (suggested `turbolinks:before-history-change` event).
@domchristie
Copy link
Collaborator

@andypearson is correct: popstate is not cancelable, so preventing a Back/Forward action is not possible.

Turbolinks clones the <body> when caching, which includes input values (but not those of <select> controls, see #238), so navigating back/forwards should be relatively safe, i.e. the person should lose their work. If you want to make this behaviour more robust, then you may wish to store input values in session storage, and then hydrate them on turbolinks:load. This approach is similar to what GitHub does with comment boxes just like this one :)

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

9 participants