I am trying to save user changes to a form on the server with AJAX on tab/window close.
This is a similar question:
Intercept page exit event
I am using this code :
$(window).bind('beforeunload', beforeUnload);
...and it seems to work fine except for when using IE11.
It seems that when the user verification alert pops up in IE11, every JS piece of code that was previously running gets halted (and my data is not sent over the wire).
So, if the user chooses to leave, everything is gone.
Has anybody made it work on that browser?
Is it possible?
EDIT :
I see now that it works sometimes and it fails on others.
When it fails, it starts the AJAX call (it hits the breakpoint at that point), but never gets in the success/fail function... (and I see nothing being sent when using Fiddler)
In summary, it first hits the AJAX call breakpoint, it then displays the confirmation dialog, and when you choose to leave the page nothing gets sent... :(
Turns out that this method of saving data is not reliable and it is working only by pure luck.
Also, the synchronous XHR is marked as deprecated by now, so it's not a good idea to use that either.
So, I guess the web is not meant to work this way...
Related
In my JS single page web app I have a reset-button that triggers 'onclick' and will use vanilla fetch() to PUT an empty JSON array to my API. Both are hosted on the same domain/server. When using Firefox (currently 86.0), the first time I push the reset button, the call is aborted. The console says NetworkError when attempting to fetch resource white the Network tab says NS_BINDING_ABORTED in the transferred column.
When I reload my app (F5) and push the same button again, it works. And also any time from now on. As the same code is executed, the failing and the working calls would send the same headers and payload.
Chrome does not show this behavior, there the first call works too.
Even stranger, this first failing PUT call in Firefox seems to only fail once per URL. The web app provides "areas" to users with the area ID in the frontend URL, e.g.
https://example.org/areas/#/myAreaA
and
https://example.org/areas/#/myAreaB
These will PUT to the API, which also has these IDs in their URLs:
https://example.org/api/areas/myAreaA/state/
and
https://example.org/api/areas/myAreaB/state/
For each of these URLs, the first PUT call fails with NS_BINDING_ABORTED but works thereafter. If I copy the URL for such an area into a new Tab or even close+open the Browser again, the Error does not appear again. The web app does not use any cookies.
The web app does a lot of other API calls to the same backend/areaID, no other show this behavior. However, this is the only PUT call, all other calls are GET/POST/HEAD/PATCH requests.
What could be the reason for the first PUT failing?
Following "NetworkError when attempting to fetch resource." only on Firefox I found the problem. It seems that Firefox' onclick event propagation interferes here with the fetch() call. As soon as I added
event.preventDefault()
in the onclick-handler before doing the actual fetch(), everything started to work again.
I am trying to make a button cancel a document request from the server while it is loading, I've tried window.stop() on Chrome but it does not prevent the page from reloading. I've also tried those lines but they get me back a blank page, which is not what I want, I need just to stop the request, as if pressing the Esc key.
document.write('<script type="text/undefined">'); or
document.write('<!--');
When I click the button and immediately press the Esc key I get the result wanted
edit: coming back to this question after some time, what I meant was actually:
"How do I prevent a request from loading the response sent by the server in user side"
We really need to see the code you are using to initiate the "document request from the server".
Here is a cool way to cancel if you are doing this type of request.
What about using abortable-fetch.
Nice demo here.
The solution to my problem was redirecting to:
http_response_code(204);
So the page stayed as it was before making the new request and but I was still able to use it normally. Thanks to those who answered anyways, the abortable fetch was also an solution.
I ran into a scenario where I was thrown an unexpected behavior only in IE8 browser. IE9 and Firefox browsers work fine. The behavior went like:
User populated a form
On purpose - user leaves a mandatory field blanked
User clicked "Submit button" and browser sent a POST request
Expected behavior - error message is thrown along with data that was already provided. Only mandatory field should be left blanked as we did not provide anything in step 2. But instead I'm getting an error message with previous data lost i.e. form empty.
And note this only happens in IE8. Any suggestions?
I am going to answer this questions myself. So, here's what happened in my scenario. It was a double click problem. But I only clicked the button once. Then how did that happen? Some programmer who worked on this project was handling a form submit where he did another submit using JavaScript. But then how did this work in Firefox or IE9+?
I used Fiddler to go deep into this - I noticed in IE8 browser two requests are sent to the server. But IE9 and Firefox correctly handles this scenario (i.e. learns about double click) and sends only 1 POST request instead of 2.
Technologies used: Spring Framework 2.0, JSP, HTML, JavaScript
Why data is lost has also to do with Server - Spring modifies the session attributes (to be specific it's a formObject which is temporarily removed and re-added) while processing requests. When there's another request at the same time it goes through another pipeline (handleInvalidSubmit) which ends up creating a new formObject and thus destroying old data.
Hope this will help others :)
I am utilizing a Google Form on a webpage. I copied the source code from the form directly onto my page so that I can modify some of the HTML instead of using an iframe. Then instead of taking the user to the google docs response page I would like to redirect them to another page.
The trouble that I am running into is with the page redirect. I was able to get this working properly in Chrome and Firefox with this:
<form target="GoogleResponse" action="https://docs.google.com/spreadsheet/
formResponse?formkey=xxxxxxxxxxxxxxxxxxxxxxxxxx&ifq;" onsubmit="
window.location = 'targetPage.html';" method="POST" id="ss-form">
IE and Safari both did the redirect automatically and the response never got written to the Google Form. If I drop the redirect, the action works perfectly in both and the response is recorded in the Google spreadsheet.
So I attempted to pull the action out and instead did it everything in onsubmit instead, like so:
<form target="GoogleResponse" onsubmit="this.action = https://docs.google.com
/spreadsheet/formResponse?formkey=xxxxxxxxxxxxxxxxxxxxxxxxxx&ifq';
window.location = 'targetPage.html';" method="POST" id="ss-form">
Same problem as before, IE and Safari both redirect, and nothing is written to the Google spreadsheet. And once again, if I remove the redirect the response gets recorded in all browsers. I can also do other stuff like throw in an alert after the action, and everything continues to work fine. The only time I see the issue is with the redirect.
So at this point the only thing I can figure is that their is some sort of conflict between the redirect and the action. I have pretty limited working knowledge of javascript and forms so any help or recommendations would be greatly appreciated!
Sounds like the browsers have not complete the form submission before handling the redirect. onsubmit happens before the submission itself so you can not handle the issue there.
Use the onload function of the target iframe for the redirect.
This has been asked in similar manner:
Old Google Form redirect after submission
Take a good look at the answer. The onload function of the iframe will handle the redirect, so the redirect will not happen until the submission is complete and a response has been given from google. So when the hidden response from google is loaded we fire a redirect. This is async functionality between the client and server. We are waiting for the server to handle the data before redirecting.
Extended note: You could try putting the redirect within a setTimeout function. This would delay the execution of the redirect, allowing the server to handle the submission first. But setTimeout requires a fixed amount of time, so if the data handling is not synchronous (ie. asynchronous) setTimeout will not work as it may fire to early or too late. Asynchronous data handling applies when the data processing requires an undetermined amount of time (such as http requests).
What would be the best way to display an animation while waiting for server-side processing of a jsp page to complete.Basically, the server side request can take more than a minute to process and until then I would like the user to have some way to get an update of how his request is getting along.I require an animated gif and a line stating that x% has been completed.
One of the methods I came across while surfing the net was to have an intermediate page that shows the animation while loading the actual page using javascript (location.href).So ,I figure use a couple of ajax calls from the intermediate page to a servlet to get the feedback.Problem is it works fine in IE 6/7 and Firefox 3.But the ajax callbacks dont seem to be getting executed in case of Chrome and Opera (The location.href part seems to mess it up and the callbacks never get executed).
If this approach is flawed how should I go about it?.And if not how can i fix this issue?
Thanks in advance
The simple way I've done this is to go to a JSP that displays a "X % completed" page (image, whatever) that reloads periodically. And when the request is complete, it redirects to an appropriate page to indicate completion. A lot simpler than AJAX, if not as fancy, and requires nothing that is browser-specific.
Try window.location='URL'. Also document.location='URL' works, but I think is deprecated.
Also to be opinionated I do think that a non-reloading web page is much saucier than just being forwarded.