I've been searching for any reasonable example of a situation, when synchronous AJAX makes sense. I've found this SO question, where the author mentions window.onbeforeunload and claims, that "the request would never stop" if the AJAX call was asynchronous.
Can anybody explain this? I mean - window.onbeforeunload is fired when the user wants to close the tab. What had to be going on to make the tab still alive, even though somebody clicked to close it? Can somebody give more specific example?
He didn't say the request will never stop; he said it will never complete. That is, your code has no hope of ever getting the response back, because the execution environment (the window) would disappear from existence before that happened.
The tab will close when window.onbeforeunload exits with a truthy value. Thus, as long as it is running, the page is waiting for the return value, and not closing. This allows a synchronous AJAX to be sent, and for the response to be received and processed. If the request is asynchronous, the code constructs XHR object, then exits, and the page (and your code) goes away.
I have never tested this, but the answerer apparently believes (and I don't think it unreasonable) that the page might not stick around long enough for an async XHR to even be sent, let alone to receive a response. Thus, if you want to be sure the server receives the information that the user closed the page, you want to have the request synchronous.
What had to be going on to make the tab still alive, even though somebody clicked to close it? Can somebody give more specific example?
Sending a synchronous XMLHttpRequest on unload is the only way to guarantee delivery of session data when a user-agent unloads the page (and may never re-visit your site again). There are two specific cases for this:
Tracking - Tracking and reporting the total session time for a user's page visit.
Batching - Coalescing and deferring delivery of batched session data to reduce the number of server requests.
The Beacon spec (navigator.sendBeacon) was designed to optimize this specific case, making it possible to send asynchronous requests guaranteed to still complete even after the page unloads.
Related
I have a problem with chrome scrollbar,on Mozilla there is no such a problem.
I have couple of synchronous ajax requests and then some info appending on the page,they need about 2 secs to load.During this time the scrollbar freezes and is not usable,when the ajax end the scroll works fine.
Javascript is completely single-threaded.
If you make multiple AJAX calls, you will receive each response as
soon as the server sends it; the order depends on the amount of time
that it takes the server to send each reply.
If your code is still running when the server replies, the reply will
only be processed after your code finishes.
You should try to load all of the data in a single request.
Source: SLaks
I might hit a wall here, in other programming languages you can start a new thread for connections/things like that, if you run multiply threads (kinda like layers) your interface stays the way it is/was.
When you use synchronous AJAX the page stops until ajax finish, so if you want the page not stop, must be asynchronous AJAX call.
You can see more here:
Documentation AJAX W3Schools
The problem you are describing is not browser behavior problem.
When you make an synchronous request it means that the the code pending for the response.
Since javascript is a single threaded language (lets ignore web-workers for now),
also the UI processing/manipulation is pending,
and this is why the browser or scroll-bar "stuck".
The reason it works on Firefox is that synchronous calls are deprecated (btw because of the "stuck" behavior), and what you are actually doing there is asynchronous request;
You can read more about it here: https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Synchronous_and_Asynchronous_Requests
In traditional javascript AJAX, we know if readystate is:
0 - The request is not initialized
1- The request has been set up
2 - The request has been sent
3 - The request is in process
4 - The request is complete.
When it comes to jQuery AJAX, we have:
complete property where we code what should happen after completion
success property where we code what should happen if the ajax request succeeds and
error property where we code what should happen if ajax request fails.
All of the above properties lets us code to do something after completion of ajax request. Where can I specify some code to execute something during processing(when readyState is 3) in Jquery Ajax??
As my AJAX script takes too long time to execute, which means, I will not attain 'complete' stage quickly. This seems like nothing is happening to the user. I wanted to initiate another ajax script at processing stage which gets information from server meanwhile and shows the user what has been done so far. Is it possible at all in Javascript? I know there is no multi-threading in Javascript.
I think I made my self clear. But, Please let me know if anything is not making any sense.
I handle this by initiating the first long running request, returning to the user immediately and allowing the process to fork server side for the extended processing.
The initial return ajax call to the user sets them up to 'watch' that process via a flag against the object ( I store them against the object in the database, but you could for instance watch file sizes or other stuff )
Subsequent ajax calls occur in a loop, each one returning setTimeout for the next call, and report on changes to that flag so the progress of the long running process is then visible. Completion of the long running process prompts NOT sending another setTimeout() and showing the overall results.
If your process is not that intensive, a simple spinner would probably do the job and no work for your server process. I usually handle that having $.ajax flip the visibility of a 'spinner' icon that's preloaded on my pages in the same spot for all.
According to jQuery's Ajax documention, they do not expose the readystate change event:
No onreadystatechange mechanism is provided, however, since success,
error, complete and statusCode cover all conceivable requirements.
It would be possible to show a loading image after the initial Ajax request is kicked off (and before getting any "complete" or "success" events, and then start polling a different URL via ajax which will give you the status of the first request, assuming your server can show progress of the long process before it completes.
When using geolocation API's navigator.geolocation.getCurrentPosition() how to deal with a negative response?
It says that the second callback function is called when there is an error. However when user chooses not to reveal his location by cancelling the request that function is never fired.
It seems that getCurrentPosition() waits for an answer indefinitely. (at least in Firefox 4)
How can I know when user presses cancel (or no etc.)
Any ideas?
See edit below
You are correct, the error handler should fire when a user denies the location request. The error object passed into the error handler should contain an error code and message letting you know the user denied the request. However, I'm not seeing this in FF4 when selecting the option Not Now from the location request dialogue.
In Chrome, the API/callbacks work exactly as expected, but in Chrome there is no 3rd option.
EDIT
Ahhh okay I found a little quirk in the behavior of this in FF4. In normal mode (not private browsing), the user will be presented 3 options:
Always share
Never share
Not Now
Never share triggers the error handler correctly, but Not Now does not.
What does this mean and how to handle it?
Well, it looks like if the user hits Not Now, you aren't going to get a response. Therefore, I would set a timeout which checks a flag that would be set by one of the handlers. If this flag is not set (meaning the handlers didn't fire in the allotted time), you can do one of two things:
Assume that the user denied the request (even though the denial was temporary)
You can ask the user for permission again (via the same call) and the user will be presented with the dialog again.
Option 2 is probably bad usability (and annoying), so it is probably best to assume they denied temporarily and ask them again (politely!) the next time they visit the site.
I created a JsFiddle to play around with this API:
http://jsfiddle.net/7yYpn/11/
I don't think it's a bug, but an intentional choice when it comes to making it difficult to make websites that provides undesirable functionalities.. (as the top answer implied; IF you request again- when someone already said no- is rather annoying...)...
The difference between "not now".. and "never".. is that the programmer of the website KNOWS.. that if "not now" was triggered.. there would be an actual prompt to the user IF he sent the request again.. hence he would be able to "force" the user's hand to EITHER accept it.. or simply block data until the user agrees..
Decent and respectful programmers want to use such information to better provide a service (and to not wait for things that won't happen).. but truth is that there are enough spammers out there to overwhelm the end user..
(and there is no need to even TRY to send the request again, if it has been answered with "never".. because.. the user will not be terrorized in the same manner.. and if the site becomes sluggish and unresponsive, the user will just close it)
Ps. OH, and SERIOUS programmers might actually take a rejection as an actual.. rejection.. and store this choice somewhere.. despite the fact that "not now" is actually not intended as an ABSOLUTE rejection, but rather a "I have decided to not take any definite stand as of yet".. so.. someone who say "not now".. if the server knows of this choice and takes it as a "no".. then there might NEVER be another request sent.. despite the person WANTING to be able to reconsider at a later date)
This question already has answers here:
JavaScript, browsers, window close - send an AJAX request or run a script on window closing
(9 answers)
Closed 6 years ago.
I would like the browser to keep the page open until the ajax requests are sent. This is what I imagine it would look like
var requestsPending = 0;
window.onbeforeunload = function() {
showPleaseWaitMessage();
while(requestsPending > 0);
}
// called before making ajax request, atomic somehow
function ajaxStarted() {
requestsPending++;
}
// called when ajax finishes, also atomic
function ajaxFinished() {
requestsPending--;
}
Unfortunately, JS doesn't do multi-threading. To my understanding, the callback (ajaxFinished) would never be executed because the browser would try to wait until the while loop finishes to execute it, and so the it would loop forever.
What's the right way to do this? Is there maybe a way to force JS to evaluate the next thing in its to-do list and then come back to the while loop? Or some syntax to "join" with an ajax call? I'm using DWR for my ajax.
Thanks,
-Max
Edit Based on your comment below, a revised answer:
If you want to block until a previously-initiated request completes, you can do it like this:
window.onbeforeunload = function(event) {
var s;
event = event || window.event;
if (requestsPending > 0) {
s = "Your most recent changes are still being saved. " +
"If you close the window now, they may not be saved.";
event.returnValue = s;
return s;
}
}
The browser will then prompt the user to ask whether they want to leave the page or stay on it, putting them in control. If they stay on the page and the request has completed while the prompt was up, the next time they go to close the page, it'll let them close it without asking.
Note that on modern browsers, your message will not be shown; instead, the browser will use a generic message. So on modern browsers, returning any non-blank string is sufficient. Still, you may want to return a useful string (such as the above) in case your user is using an obsolete browser that will still show it.
More on asking the user whether to cancel close events here and here.
Old answer :
Ideally, if possible, you want to avoid doing this. :-)
If you can't avoid it, it's possible to make an Ajax request synchronous, so that it blocks the onbeforeunload process until it completes. I don't know DWR, but I expect it has a flag to control whether the request is synchronous or not. In the raw XmlHTTPRequest API, this is the third parameter to open:
req.open('GET', 'http://www.mozilla.org/', false);
^ false = synchronous
Most libraries will have an equivalent. For instance, in Prototype, it's the asynchronous: false flag in the options.
But again, if you can possibly avoid firing off Ajax requests as part of the page unload, I would. There will be a noticeable delay while the request is set up, transmitted, and completed. Much better to have the server use a timeout to close down whatever it is that you're trying to close down with this. (It can be a fairly short timeout; you can keep the session alive by using asynchronous Ajax requests periodically in the page while it's open — say, one a minute, and time out after two minutes.)
In short, you cannot (and shouldn't) do this. If a user closes the browser, it's closing...no unload style events are guaranteed to finish, and something doing AJAX with involves latency is more unlikely to finish.
You should look at firing your events at another point, or change the approach altogether, but making an AJAX call in an unload event is going to unreliable, at best.
As an addendum to the above on the shouldn't part, think about it this way, how many tabs do you usually have open on any given window? I typically have 4-6 chrome windows open with 5-12 tabs each...should my browser window hang open because 1 of those tabs wants to make some AJAX request I don't care about? I wouldn't want it to as a user, so I wouldn't try and do it as a developer. This is just an opinion of course, but food for thought.
I'm implementing click tracking from various pages in our corporate intranet in order to add some sorely needed crowd-sourced popular link features ("most popular links in your department in the last 24 hours", etc.)
I'm using jQuery's .live() to bind to the mousedown event for all link elements on the page, filter the event, and then fire off a pseudo-ajax request with various data to a back-end server before returning true so that the link action fires:
$("#contentarea a").live("mousedown", function(ev) {
//
// detect event, find closest link, process it here
//
$.ajax({
url: 'my-url',
cache: false,
dataType: 'jsonp',
jsonp: 'cb',
data: myDataString,
success: function() {
// silence is golden -- server does send success JSONP but
// regardless of success or failure, we allow the user to continue
}
});
return true; // allow event to continue, user leaves the page.
}
As you can probably guess from the above, I have several constraints:
The back-end tracking server is on a different sub-domain from the calling page. I can't get round this. That's why I am using JSONP (and GET) as opposed to proper AJAX with POST. I can't implement an AJAX proxy as the web servers do not have outbound network access for scripts.
This is probably not relevant, but in the interest of full disclosure, the content and script is inside a "main content" iframe (and this is not going to change. I will likely eventually move the event listener to the parent frame to monitor it's links and all child content, but step 1 is getting it to work properly in the simplified case of "1 child window"). Parent and child are same domain.
The back-end is IIS/ASP (again, a constraint -- don't ask!), so I can't immediately fork the back-end process or otherwise terminate the response but keep processing like I could on a better platform
Despite all this, for the most part, the system works -- I click links on the page, and they appear in the database pretty seamlessly.
However it isn't reliable -- for a large number of links, particularly off-site links that have their target set to "_top", they don't appear. If the link is opened in a new tab or window, it registers OK.
I have ruled out script errors -- it seems that either:
(a) the request is never making it to the back-end in time; or
(b) the request is making it, but ASP is detecting that the client is disconnecting shortly afterwards, and as it is a GET request, is not processing it.
I suspect (b), since latency to the server is very fast and many links register OK. If I put in an alert pop-up after the event fires, or set the return value to false, the click is registered OK.
Any advice on how I can solve this (in the context that I cannot change my constraints)? I can't make the GET request synchronous as it is not true AJAX.
Q: Would it work better if I was making a POST request to ASP? If (b) is the culprit would it behave differently for POST vs GET? If so, I could use a hidden iframe/form to POST the data. however, I suspect this would be slower and more clunky, and might still not make it in time. I wouldn't be able to listen to see if the request completes because it is cross-domain.
Q: Can I just add a delay to the script after the GET request is fired off? How do I do this in a single-threaded way? I need to return true from my function, to ensure the default event eventually fires, so I can't use setTimeout(). Would a tight loop waiting for 'success' to fire and set some variable work? I'm worried that this would freeze up things too much and the response would be slowed down. I assume the jQuery delay() plugin is just a loop too?
Or is something else I haven't thought of likely to be the culprit?
I don't need bullet-proof reliability. If all links are equally catchable 95% of the time it is fine. However right now, some links are catchable 100% of the time, while others are uncatchable -- which isn't going to cut it for what I want to achieve.
Thanks in advance.
I would try a different approach. You can bind to a different event like:
$(window).unload(function(event) {
// tracking code here
});
I would try to return false from the link event handler, remember the URL and navigate away only when JSONP request succeeds. Hopefully it shouldn't add too much latency. Considering you are on the inranet, it might be OK.
Solved!
The short answer is: there is no reliable way to do this cross-domain with a GET request. I tried all sorts, including storing the event and trying to replay the event later, and all manner of hacks to try to get that to work.
I then tried tight loops, and they weren't reliable either.
Finally, I just gave in and used a dynamically created form that POSTed the results, with the target set to a hidden iFrame.
That works reliably -- it seems the browser pauses to finish its POST request before moving on, and ASP honours the POST. Turns out it's not 'clunky' at all. Sure, due to the browser security model I can't see the result... but it doesn't matter in this case.
I am now kicking myself that I didn't try that option first.