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.
Related
I want to display a toast for a few seconds whenever a user does something, eg. when they log in to the app. I am using a form on /login/+page.svelte to login, with the database interaction in /login/page.server.js. And I am using a writable store to store toasts.
On form submit, the page refreshes, so my store is cleared and the toast is lost. It seems the event flow is:
submit form to /login/page.server.js
page.server.js does some stuff
page.server.js sends back the full page and the browser reloads to the new full page.
I understand you can use preventdefault to prevent all those steps, but I only want to prevent the reloading. Preventing everything does not seem optimal (there are probably some other stuff I don't even know I'm preventing).
Is there a nicer way of interacting between a page.svelte and a page.server.js without reload (and thus clearing, probably all, stores) than preventdefault + using a manual fetch?
REPL I was playing around with that demonstrates the toast staying full 3 seconds generally, but immediately disappearing on normal form submit.
https://svelte.dev/repl/8b61434332ca471b83cbf039bf1f3fc9?version=3.22.0
The intended workflow for forms is to use form actions and enhance, which automatically processes the form asynchronously (which falls back to the hard reload if JS is disabled).
I am developing a web application. And I wrote some JS script to be executed on document ready. But in chrome when we click on back button and go back to previous page it is executing all the js script again. But when I use same on firefox it do not execute the JS.
I have an accordion on a page and when user open any accordion and go on one of the link under the accordion and after that if again clicks the back button on the accordion page chrome is closing all the accordions as I have written the script to close all these on document ready. But firefox do not close.
Is there any way to fix this with javascript? So that I can put any condition like if(history.forward.length < 1){ do this....}
You can use the pageshow event to guarantee you always detect navigation to a particular page, regardless of whether the user presses the back/forward button or selects a link, and regardless of which browser is being used.
Then you can perform checks regarding the state of UI and perform logic as required (i.e. modify UI, prevent execution of additional JS).
window.addEventListener('pageshow', function(event) {
// check state of UI, etc.
});
The solution that came to my mind is using sessionStorage to know if it is a first time loading or not. Or even better, you can keep state of your accordions in session storage so it always be the way the user want.
In my case, the iframe was a hidden iframe (width and height zero).
This iframe is just an workaround from legacy system, developed 12 years ago. But still using nowadays on current application.
To solve it, i just redirected the page loaded into iframe to the blank page.
Example:
page_loaded_into_iframe.php
<?php
//do the php stuffs
?>
<script>
alert("hello world");
location.href = "about:blank"; // here, where the the magic happens!
</script>
Once pressed the "back button", the browser will reload a blank page.
Be aware that this might be not applicable if your case is not similar to mine.
In the Chrome Extension you can use the function:
chrome.webNavigation.onCommitted.addListener(function callback)
and in the callback function you may take a look to the arguments:
transitionType + transitionQualifiers
to look for:
"forward_back" The user used the Forward or Back button to initiate the navigation.
For deatils see chrome.webNavigation
Of course, this event can be communicated to the content script with the usual message model (refer to: Message Passing
User clicks and button gets disabled.
User reloads page.
Button is still disabled.
I want it to be enabled.
I have tried anything from onkeypress f5 to onbeforeunload and nothing works.
This is an issue I had the misfortune of encountering before, since most browsers rely more and more on local cache to improve page loading. While in chrome usually another page refresh fix it, Firefox is more stubborn.
I solved it by running a function using body onload event. This function detects those incorrectly disabled elements and re-enables them.
To avoid errors there must be a check to indicate weather this page has the elements to check in the first place.
In Safari Browser, on a page with a form, there is a system modal popup that opens when the user tries to close the browser's tab and the form hasn't been validated. Text says: You have entered text on “[name of the page]”. If you close the window, your changes will be lost. Do you want to close the window anyway?
This behavior is ok when the post redirects to another the page. On our site, we have a page that validates a form using an Ajax Request. As the page is not reloaded, even if the form has been submitted, the popup appears, and it might feel strange for the end user.
The post is triggered by a button:
Forms are validated using the jQuery Validation plugin
Plugin options include a submitHandler option that return false;
Date are sent via $.post, and a message informs user for success/failure.
Does anyone have an idea about how to avoid this popup to be triggered once the call returns? We'd wish not to force a reload in that case.
Note that this behavior can be changed by the user, but not very easily...
I can't replicate this in Safari on Windows.
Maybe try emptying/resetting the input fields once the form has been submitted, only if there weren't any errors with the submission of course, or better yet, remove the form completely, if it's not needed after. Of course using DOM manipulation, not by reloading the page.
On a side note, seeing the filled-out form after it's been sent (even if you're showing a confirmation message) also can be strange for the user (unless it's a multiple-use form and this behaviour is expected).
UPDATE: tested on a Mac Safari, it's behaving as you described, but if I remove what I typed (that made the browser alert me in the first place), it doesn't come up. So, simple reset of the fields should do the trick.
I have JSP where i submit a form using javascript. Its a popup window so after submission popup must be closed. I used following code:
document.forms["formname"].submit();
window.close();
Problem is - Form gets submitted successfully but window doesnt get closed.
Its work fine in IE.
I have a doubt how it is working in IE.
Javascript doesn't have any control after/until you submit the form and control is returned back to the browser. You should use some another mechanism to close the window after submission of form.
Instead of closing the window from a script running in the context of the window to be closed, try closing it from the context of the window that opened it. For example:
var popup;
function pop() {
popup = window.open('foo', 'mypopup', 'menubar=no,location=no,resizable=no,scrollbars=no,status=no');
console.log(popup);
}
function unpop() {
popup.close(); // close the popup
}
This works for me in Firefox. You can test it live here.
As you've discovered, once you submit the form, you've turned over control to the browser and there is no guarantee that any more javascript in that page will execute. It may just immediately start loading the result page. As such, you have several options:
You can make the result page close itself. So, when the result page loads after the submit, it contains its own window.close().
You can use ajax instead of a form submit to send the data to your server. Then, the lines after the ajax code sends the data will execute. To be safe, you may want to wait until the ajax call returns successfully before closing the window (depending upon what you're doing and how important it is to know whether it succeeded or not).
You can control things from the parent window that opened the form and close things from there.