Inconsistency with window.history.back() - javascript

I have the following code in an MVC view that I'm using to test window.history.back()
If the user clicks the link (highlighted in red) within the paragraph tag, window.history.back() executes as I would expect. It takes me back to the prior page with state maintained on that page. However, if the user clicks the button, I don't get the same behavior. The current view is reloaded, or at least an attempt is made to reload the current page. But it fails. And it doesn't matter if the jQuery is executed, or I put the window.history.back() call within the Button onClick, the same thing happens.
A piece of information which might be helpful. The button is inside an HTML.BeginForm and the line in the paragraph tag is not.
Anyone know why this is happening?

The browser is probably interpreting the button as a submit button and submitting the form, thus causing a page refresh. Adding type="button" will prevent that.
<button type="button">Cancel</button>

$('#cancelButton').click(function(e){
e.preventDefault();
/* ... code ... */
});

Related

Keep scroll position in ADF page

I have a page with few forms in it and a submit button to save the records. If there is any errors then I m displaying the error messages programmatically in faces message .
But after clicking on the ok button on the af message, the page scrolls to the top and I have to scroll down again to click the button.
Is there any way to save the scroll position in ADF . I tried to call Java script
Window.scrollto () method
But for other methods it's working fine but not after clicking on the af message ok button.
Please let me know any way to scroll down to the bottom of the page.
markosca already gave the correct hints as a comment.
I'll clarify a bit on this for the sake of a complete answer:
If your buttons trigger an action, always a complete new site will be loaded.
Even if the "new" site is equal to the old one, it will seem as if the site has scrolled up.
If your buttons have an actionListener registered, this scrolling will also happen. Even if you put an addPartialTarget(...) inside that registered Java-method.
So, how to solve this? It's easy, just use an actionListener and the attribute partialSubmit="true" on the button or link.
Only than a partial submit will be executed instead of a full page reload.
And don't forget to either use addPartialTarget(...) in Java or the attribute partialTriggers="..." on the components which should update because of that partial submit.

g:submitButton- onclick doesn't work

I have the following g:submitButton:
<g:submitButton name="next" class="signup-button skyblue-btn pull-right pl-pr-36" value="${message(code:"buttons.ok")}" onclick="return showSpinnerSignUp()"/>
I define the showSpinnerSignUp() in the JS file:
$(function() {
function showSpinnerSignUp(){
$('.spinner-ctn').show();
return true;
}
});
The spinner is not displayed (the onclick doesn't work).
This is the default behaviour of a form submission in the browser. You have registered a showSpinnerSignUp() method on the click of a button while the click on that same button is responsible for submitting the enclosing form.
Since the browser's built-in behavior for submitting forms works by making a full roundtrip to the server, that immediately interrupts your code execution of onclick event because your browser is navigating away from your current page.
This can be simulated as if you had clicked your button and refreshed the page immediately. Your current setup might work when you deploy this to the production server, but the possibility of working this setup locally is low because a local development server used to run on a faster machine so the page refresh time of form submission is quite faster.
To verify this happening, open your browser's console and call the method showSpinnerSignUp() directly (remember to remove it from $(function() {}) temporarily) and see if the spinner is showing up.
Also, there is an option to Preserve Logs which keeps the Javascript console logs even after page refresh. So, put a simple console.log() inside your method call and then try hitting that button. You'll see your method is called but no spinner is displayed due to form submission.

submitting a POST form calls my document.ready() function again?

I have an index.php page which imports a "myjs.js" file which includes a document.ready() function. Inside the document.ready() function, I show the home tab by calling .hide(); on all the divs that represent the other tabs. I also have the code so that when i click on a tab, it hides the current div and shows the div that goes with the clicked tab.
one of the tabs that I have is the profile tab, where I have a POST form with a submit button. When I click the submit button, the page goes back to the home tab (exactly the same way as when I go to the page initially). Is there a way from preventing this from happening? The submit button corresponds to some php that i have at the top of my index.php page but I don't want to leave the profile tab when I click the button :(.
Thanks!
EDIT:
actually, you can log on and see for yourselves, the code is live here: www.aaemexico.com/login.php
use credentials:
username: asdf
password: asdf
go to "perfil" tab and choose a new password (change it to asdf so that others can still access it) and click the button. preferably, i would like to not go back to the home tab after i click the button
It sounds like the form is being submitted and the page is posting. You could probably override the submit function and prevent default events to prevent the document.ready from firing again.
Or, in your document.ready, check if the page is already loaded and don't do anything if it is.

Stay on same page after button click event

We use a survey link for feedback A suffix is use after the URL to make sure all SP components are not seen. When suffix is used there is a cancel button at the bottom which needs to be hidden or removed. And also when user clicks on finish button it navigates to a blank page, is it possible to give an alert like "Thanks for your feedback" and stay on the same page after button click event.
I am using this piece of code and this doesn't help.
<input type="button" Text="Finish" value="Form Action" name="btnFormAction0" onclick="javascript: {ddwrt:GenFireServerEvent ('__commit)')};alert('Your survey has been submitted Successfully');window.parent.location='https://team.SharePoint.com/teams/Prod/Lists/Comm_Mgmt/newform.aspx?IsDlg=1'" />
The Javascript code inside of the onclick attribute has errors.
GenFireServerEvent ('__commit)'
Should be
GenFireServerEvent('__commit')
If the page is still redirected, then I believe it may be due to some code in the GenFireServerEvent function or an HTTP 300 Redirection Response from your backend.
My suggestion is that, your finish button redirect user to a new page, then on the new page, you create a on document ready call, over there you can trigger an alter function. please me know if you need more details about this.
cheers

SharePoint <button> elements perform an unwanted reload of the page

I have an aspx page on my SharePoint site, which I have included tags. For some reason, every button on the page will reload the page when clicked. Even the buttons with no attributes (id, class, etc) or functions will reload the page when clicked. How can I fix this issue? I can't even see what's going on in the debugger because I'm not calling any reload functions, so I have no idea where to place a breakpoint.
Thank you in advance for your help, I really appreciate it.
The problem here is with the <button> tag. Its default behavior is to act as a submit button unless otherwise declared and will reload.
To keep your <button> tag, add type='button' to the button element. I think that prevents the reload.
Or you could go with the ole <input> tag with a type='button'. That keeps the reload from happening as well.
Or some other html element with an onclick event will work too.
First search for a function called doPostback and set a breakpoint on the entry point and click a button. If you hit this breakpoint it could mean that auto post back is turned on for the control generating the button. However if you trigger that breakpoint you should be able to look at the stack trace to figure out how you got there.
If that doesn't work, use the F12 tools in the browser, start with the HTML section and search (Ctrl-F) for the word "click". Then go to the script tab and do the same for each JavaScript file. If all of the buttons exhibit the behavior there is most likely a click event registered. Possibly with jQuery that looks like this $('button') so that it matches all buttons on the page and registers a click handler.
If that doesn't find it, and you have access download one of the master pages from http://startermasterpages.codeplex.com/ and temporarily replace your master page with one of these. Take a screenshot of the scripts that are loading on your page first. Then add them to the starter master page one at a time until the unwanted behavior returns. Then set a breakpoint on every function entry point in that script and click a button and see where you land.

Categories