how to detect browser back and forward button clicks
I need to know when a visitor to my site is clicking the back or forward button. The reason is I have a "tabstrip" that hilites the currently selected tab and the target document is displayed in an iframe. If I click the back or forward buttons the page is updated with the last or next document in the iframe, but the tabstrip is not updated to reflect the change. Part of this is due to me not knowing how to update the tabstrip, but also because I don't know how to detect the back or forward buttons being clicked.
So I need to know how to detect those button clicks. Also, in researching this, I noticed that there seems to be an idea that you can't distinguish between the forward and back button, only that a button was clicked. That doesn't make sense given that each button has a specific action that is opposite of the other. I need to know the truth about this.
Finally, as much as I use only Firefox myself, I know there will be others who use other browsers. Is there any difference between detecting the back and forward buttons on other browsers compared to Firefox?
One of the pages I need this for is here
Edit 15 March 2022:
I had to fix the link because I had renamed the page when I finished the work on its layout. Also, since I asked this question I have realized another similar and sort-of related issue on a different page: https://wayneca.neocities.org/WebDesi.../TagList.html. The relation is that the back and forward buttons don't correctly reload the page. The difference is that this one is concerning named links.
When you click a link in the table on the left it correctly moves the document in the right table to the point where the matching id anchor is. But when you click the back or forward button the tables do not shift back to where they were on the page as reloaded. The back and forward buttons work fine if the link anchors and id anchors are not in tables.
I have been told about the history functions, but I have found no examples of using it to correct the issue in either of the above cases. Is someone here able to point me to examples of using the history to make a selected link reset back to where it was or reload a page with the last jump point being reset correctly?
Also, why does the named link thing work without tables but not with tables?
Modified
Chosen solution
Try this:
<script> // Reposition page after a hash change window.addEventListener('hashchange', function() { if (location.hash.length > 0){ // Navigate to the hash document.getElementById(location.hash.substr(1)).scrollIntoView(); } else { // Go the beginning document.getElementById('COMMENT1').scrollIntoView(); document.body.scrollIntoView(); } }, false); </script>Skaityti atsakymą kartu su kontekstu 👍 1
All Replies (6)
Do you mean Firefox's toolbar buttons? You cannot detect that directly. However, the "hash" on the URL changes when the user goes forward/back between anchors in the page, so you could try hooking into the hashchange event.
https://developer.mozilla.org/docs/Web/API/Window/hashchange_event
Would that detect the navigation you're concerned about?
I looked at the page you linked to. That could be my solution, but I have at least 85 links using the hashtag identifier. Would I have to create a different function for each one? I really don't understand the new terminology. I can read it, but it doesn't make sense to me. And the examples don't really tell me how to use it. I could use an example that does what I need it to do. I can always adapt it to my page. I just don't know how to write the code myself.
Modified
Chosen Solution
Try this:
<script> // Reposition page after a hash change window.addEventListener('hashchange', function() { if (location.hash.length > 0){ // Navigate to the hash document.getElementById(location.hash.substr(1)).scrollIntoView(); } else { // Go the beginning document.getElementById('COMMENT1').scrollIntoView(); document.body.scrollIntoView(); } }, false); </script>
That was exactly what I needed. Thanks so much. Now I can focus on getting the rest of the document finished. I will also be using this as a guide for dealing with the other page that doesn't reselect the previous link "tab" when the back or forward button is clicked. I'm sure the hashchange event won't work there, but this at least gives me a clue of how to write the code. I have included in the source credit to you for the script, and I will be including a link to this post for others to read.
I'm glad to hear it worked in real life (I was pasting the code into the Web Console for testing).
I was thinking about that left column, but I wasn't sure of the most polite way to handle it. What I mean is, the script fires both for going back/forward, and for user clicks, because the hash changes in both cases. Because of that, lining up the left column with the right column all the time might be more annoying than helpful because people would lose their place in the list. There is a way to check whether the left panel needs to move and I implemented that in the following You could test and see what you think.
<script> window.addEventListener('hashchange', function() { if (location.hash.length > 0){ // Navigate to the hash document.getElementById(location.hash.substr(1)).scrollIntoView(); // Line up the left panel only if needed (if vertical position of link is too high/low) var el = document.querySelector('a[href="' + location.hash + '"]'); if (el){ var rect = el.getBoundingClientRect(); if (rect.top < 0 || rect.bottom > document.documentElement.clientHeight) el.scrollIntoView(); } } else { // Go the beginning document.getElementById('COMMENT1').scrollIntoView(); // Line up the left panel document.querySelector('a[href="#COMMENT1"]').scrollIntoView(); // To top of page document.body.scrollIntoView(); } }, false); </script>
That actually fixes it just fine. I wasn't going to worry about the left table so much as I figured the most important part is the right table, but this looks much better than leaving the left table alone. Thanks again!