I have a heavily interactive page that, while it does not use a form, does have objects that maintain state. This state is completely messed up when someone navigates away from the page and then comes back to it again with the back button. So, I'd like to be able to detect when someone uses the "back" button to navigate to my page, and have it reset the content at that point. How can I accomplish this?
I found one other question that addressed this issue, but it is very out-of-date (from 2011), doesn't mention anything about support for Chrome, and I'd rather not use JQuery if I don't have to (I'm not using it anywhere else at the moment).
Related
I have a very rudimentary SPA built in vanilla JS. There are two buttons that the user can use to navigate between pages, for example:
buttonProfile.addEventListener("click", function () {
window.history.pushState({}, "", "profile/");
var updatePage = new Event("update-page");
dispatchEvent(updatePage);
});
Somewhere in the app, I have an event listener that listens to update-page to refresh the content that needs to be refreshed (without ever reloading the page) based on the current URL. Everything works fine.
However, I noted two odd behaviours:
If the user starts on Page A and then moves to Page B, the user will need to go back twice (button on the browser) in order to go back to Page A.
If the user goes back from Page B to Page A, once they are back to Page A the "forward" button on the browser will become greyed out.
EDIT
In case it helps, I noted I have the same issue when I use other people's SPAs that have a similar implementation. See this simple demo for example: DEMO | CODE
Steps to reproduce:
Click on About, then Contact, then again About, then again Contact.
Now, if you press Back once you'll go back to About. However, if you press it again you'll stay on About. You'll have to press it again to move to Contact and once you do, the Forward button will be disabled.
EDIT 2
I just realize that both my site and the site I posted above work fine when I run my browser in Incognito. There must be some other problem with my Chrome (though I have no idea what).
Okay, I found it. It was the Matter official Chrome extension. Not sure what exactly caused the issue though.
I am trying to decide whether to do a somewhat expensive javascript-ajaxing-to-the-server operation, but it is only worth doing if the user can see the web page, so I'm trying to detect that.
I was initially excited to find the "visibilitychange" API, but it looks like that only detects if the web page is in a hidden tab. If the user opens up a new browser window instead of a new tab, the event isn't called. Nor is it called when the user changes to a different app.
I also think I'd like to slow down the operation if the browser isn't in the foreground, so there are really three states:
"request-every-5-seconds" Does the browser have the input focus?
"request-every-minute" Is any part of the page actually on the user's display?
"don't-request" the browser is buried under another window.
That way, a user who goes to my webpage and leaves the browser open won't be using resources either on the server or their computer.
For the first state monitoring "onfocus" mostly works, but the focus can get lost to the developer tools. That's a little annoying, but it isn't typical of a customer, so I can live with that.
For the second state, I have no idea where to start. One idea I had was to detect whether the browser is actually "painting", but I haven't found any way to detect that.
How do you decide whether it is worth checking for updates?
[note: I'm using jQuery already, so a jQuery-based answer is fine.]
Thanks.
I have the following scenario, a user is scrolled some wheres down a search page. They click on an item and after they are done viewing the item they hit the back button. The back button brings the user back to their exact location within the search page as it's suppose to. After a second, the page auto scrolls to the top of the search results. You can see this behavior in action cardaddy.com/forsale
I've spent a couple hours trying to figure this out with no success. I'm not aware of any js causing this issue either. Please feel free to take a look. Any suggestions would be great since this is destroying my ux
I though maybe the forward from my root domain to www.domain.com with godaddy.com may of been the cause, so i changed that behavior around to use amazons name server eliminating the forwarding. I thought I repaired the issue as it seem repaired on the desktop, but it still seems to happen on mobile.
As far as I know, this behaviour depends on your browser.
The back button brings you to the last site you visited and loads this site new. So the effect to stay at the possition is caused by the browser engine.
1 way of doing it would be to save the location of the page and restore to that location when back button is clicked
on click : var position = $(window).scrollTop();
On back button : $(window).scrollTop(position);
We have an app with a list, that when a record is clicked a popup modal div is displayed, that is used to edit a user record. The div contains an iframe.
In the iframe, the user clicks save and the form is posted back, where server side validation occurs. If there is an error, the user is presented the error information and a go back button.
The go back button is wired to history.go(-1)
When it is clicked, in IE8/9/10 and Chrome, the iframe reverts back to the form with the user's changes still in it, allowing them to remedy any problems.
In IE11, it sends the parent page back to it's last page, so not only do you lose the div, but you lose the list.
Is there a way I can make IE11 behave like it was in IE10?
FWIW, we do perform basic client validation, such as checking for valid emails, mandatory fields etc, but we also do this in the backend, as well as checking that more complex rules to do with business relationships etc.
Thanks!
With IE11 finally going HTML5, you can save your history state so you would use push and popstate. Using this, you'll be able to control your "back" (working fine here).
Our application forbids going back for several reasons.
Basically because that's just how our application works (JSF with facelets as GUI)
You always have to enter on the welcome site, once you chose an application-flow you can only leave / abort when you tell the application (e.g. press a button). If you just browse away e.g. enter "example.com" in the address bar the state of your flow gets saved and once you relogin, you can resume the work. Going back is only possible when it was specifically designed like this with a 'back' submit - button.
Of course users keep pressing the 'back' button (i would do so as well) and they keep getting 'error: session out of synch'. This is a learning process and a couple years ago we just disabled the back-button to make things clear. Sadly this is no longer supported.
So instead of teaching the user the hard way and forcing him to relogin, are there some good alternatives I'm missing?
i found this link which should offer 3 methods to disable the back button - but in reality it just further confirms the fact that it is impossible to do it in a semi-nice way.
when the user tries to go to a previous page you can redirect him to the page he should be at in other words catch the "out of sync" and redirect him
You might find a workable solution here How do I insert an entry into browsing history via JavaScript
by inserting an extra step into the browser's history (perhaps a link to the current page with query string parameters that result in a nice big red box message to the user), or you could try attaching an event handler to the OnBeforeUnload event so the user gets a confirmation dialog when trying to leave the page (you'd want to remove the handler when the submit button was clicked).