If I have a form, and don't click submit before hand, using standard javascript history.
<button onclick="history.go(-1);">Back </button>
will bring me back to the previous page. However, if I click submit, and error come out (validation).
the back button will bring me back to the same page (the page before the submit error happen).
How can I create a back button where it always bring to the previous page, regardless error of validation.
Thank you
Going by the actual history isn't a great way of doing what you want. What you see happening here, is of course expected behavior, since submitting the form over and over will just add the page with the form to the history over and over. And by design, for security reasons, there isn't a way to check arbitrarily far back to the last page the user was on on your site that wasn't the form.
Therefore, I think a solution in Cake would be better. If the user can only arrive on the page from one place, you could make the button just link back to that page, rather than depending on the history. Alternatively, I would store in session the page that the user came from originally, and be careful to not rewrite it as long as the user stays on the form, and then link to that on the back button.
Related
So, I'n NOT a frontend guy, please bear with me..
I have pages, where you submit forms (target and current urls are identical) a number of times, before you wan't to go back to the previous page.
The way the submits are processed, is that the form is posted, and then the user is redirected, so that a reload doesn't re-submit(POST) the form - I'm not sure if this is the optimal approach to achieve this..
The issue is that this will only take the user back to the same page, since if eg. a form on page A was submitted twice, the history will have:
page A (current)
page A (submit, yielding a redirect)
page A (previous load)
page A (submit, yielding a redirect)
page A (original load)
previous page
Now I'd like the back button to take the user back to the previous page (#6), and in order to do that I'm guessing I'd need to introduce code on each page (with forms at least) which:
checks if the referrer has identical url as the current one, and if so, does history.popState
on submitting any form, check if the target and current urls are identical does history.popState
Is this a sound strategy, or is there are better way to achieve this?
Html
<a href="index.html"
onclick="handleClick(this);">Click</a>
Javascript
const handleClick = (e) =>{
locaiton.replace(e.href);
return false;
}
This doesn't seem possible, so I took another route, where I'd avoid using the back button, but rather offer links to the previous page, based on the context.
I have the following flow:
HOME => DEVICES => ADD NEW => SELECT TYPE => PAIR
Users can of course go back at any time. Now after pairing is complete I go to the DEVICES index page again.
When a user presses the back button on that page, it returns to PAIR (which I don't want), I want it to go to HOME.
I've looked at ReplaceState on the final step which changes the PAIR page by the HOME page before redirecting to DEVICES. That way when the user presses back in the DEVICES page he/she comes back at the home page (great!), however when the user then presses BACK again he arrives at SELECT TYPE which I don't want.
How can I accomplish that when the PAIR is done, the ADD NEW, SELECT TYPE and PAIR page are removed from history?
Side note: I'm using Turbolinks and Rails, although I believe the answer would be JS.
AFAIK, you cannot delete from browser history. But you can prevent saving history by location.replace (see https://stackoverflow.com/a/21820194/4486609) or do another mad thing like turning off back button at all, but...
if you have classic web app (not SPA) then you have some system to prevent user jump to abitrary step at your wizard, and if you have it, it is already solves such problem, isn't it?
I have a problem with the pop-up:
This page is asking you to confirm that you want to leave - data you have entered may not be saved.
I am using JavaServer Faces and JavaScript, and after navigating away (and saving every data that I need) if on the next page I click on any button, I see the pop-up. So it doesn't even appear on the page when the data was given, but on the next one, where I have just a few buttons to select the next action.
Does any easy way exist, to find out which part of the data is not saved?
Here's the situation.
A user goes to the #new action, clicks submit form, and the object is created. The user is shown the show page
The user realizes something is wrong, so they click back (even though there's clearly an edit button there)
The user fixes whatever needs fixing and clicks submit again, thus creating a new object
What I want to do is have the user directed to the edit action when they click back on the show page. It's also got to be IE 7+ compliant. Is this possible?
Another alternative I was considering was creating a random string on a hidden field on the #new page, and using that to check whether the object's already been created.
Thoughts?
I would use in javascript
document.referrer
on the new page to see where the user came from and if it's the created page, you can then do whatever is necessary to go to the edit view.
Apologies for the title, I found it hard to define my question succintly and that was the best I could do. If someone wants to edit it to add a better title then please, be my guest.
Anyway, the question. We have on our webpage the capability for users to delete something. They do this by clicking on a delete link, something that looks something like:
<a href="http://localhost/a/path/remove-thing.html?ID=42" onclick="return confirm('Are you sure you want to remove this thing?');" >Remove this thing!</a>
Now, obviously, normally when the user clicks on that link they get a javascript confirm box which asks them to confirm that they want to delete the thing. If they click cencel, the onclick event is false and so the delete doesnt happen; if they click okay then it does.
My problem is that if the user clicks on another link in the page (to anywhere), then quickly clicks on the delete link before the first page loads, the javascript never gets fired, but the thing is deleted - when they clicked on "Remove this thing!" they fired off that URL instead of the one they originally clicked. Is there a way to avoid this? Are we doing the confirm 'wrong'? I assume it has something to do with the browser shutting off the javascript checking when you click the first link as it prepares to render a new page, but then still accepting a change in URL before the page has gone...
(This has been tested in Firefox 3.6 and confirmed a problem there. No other browsers tested yet.)
one way around this which would degrade a bit more gracefully would be something like:
create a separate confirmation page which these links send you to
use javascript to show the dialog, and if 'yes', send the user directly to the delete page
this way it works even without javascript, and should hopefully eliminate your issue
EDIT
if js will always be present, you can always have the default link be empty, and redirect the user after confirmation
You're really having a couple of problems. I think you would be better off taking a progressive enhancement approach.
What happens to your users if they don't have the JavaScript? I know that people rarely turn off JavaScript, but it's still a useful thing to consider. Without JavaScript, people will be deleting items without confirmation.
You're better off linking to a delete form that asks "Are you sure you want to delete X?" and has "Delete" and "Cancel" buttons. After the form submits or they press cancel, you can send them back to the original page. *
Now for the progressive enhancement: attach a click event handler to the "delete" link that pulls in the "are you sure?" form via AJAX or builds it from scratch. Have the form replace the delete link. If they click the "Delete" button, just submit the form as before. If they click cancel there's no need to reload the page - just remove the form and restore the original "delete" link.
* as an aside, make sure the form is a post form and that it has CSRF protection. If you don't know about CSRF attacks, definitely read up on them.