What I want to do: dispose of a session upon detecting an "OnBeforeUnload" event in the client. I know it doesn't fire 100% of times (90% accuracy works fine for me)
Here I saw how to do it with ajax, this system, however, breaks down with ajax: I can't use it at all.
I'm searching for ways of doing it
In short, you can't. You can't hold a user's browser hostage, which is what this would allow as an exploit if you could do what you want (e.g. redirecting on page exit). AJAX is your only option for a server-side call, and as you noted, that's unreliable as well.
I do not know if it is possible to do this during a "onBeforeUnload", but maybe you could try it.
Inject a image to you web page like:
<img src="yourscript?param1=value1¶m2=value2" />
From the server side just return an empty image.
You're probably going to need to hook a synchronous call rather than AsynchronousJAX.
Related
I was wondering if there is some cleaner way to implement event firing on input tag value change (i want it to fire every time character is entered/deleted) and make these values visible in controller other than using ajax?
So the way I know now is implementing JavaScript snippet which would attach addEventListener to input element (like here) and would make ajax call to initial rails controller to pass the new input tag value. However ajax feels like too much as opposed to if there would be something native in rails, I just can't seem to find it.
If you need anything from browser going out to server (written in any language) without refreshing the page, Ajax is the way to go. Now-a-days, fetch would be another alternative, which works in similar manner.
If you need every key-stroke to be sent to server (controller), you should add a keyup event listener. In the event listener function, make an Ajax/fetch call to the endpoint, and return relevant information from your controller.
Do remember to include a timestamp in the requests, and send them back in response though. In most such scenarios, you'd want to be differentiate between "what is new" vs "what is stale", in case user types too fast. Due to network delays, responses typically do not come back in same order as the requests were made in.
how do I set up a global event listener which keeps on listening for server calls. These server calls will be requests for setting up a session with another user. The best example I can give to put my point through to you is, its like skype, whenever anyone logs in, that user has an eventlistener which listens for any calls which other users may want to make to this user. So could I use something like the live or the delegate function in jquery, or do you have some other suggestions. I would highly appreciate it if you could direct me in the right direction. Thanks.
After loads of research, this is what I found and works perfectly:
http://www.html5rocks.com/en/tutorials/eventsource/basics/
HTML5 rocks!!!!
I also found an alternative ans, where I use the workers and open a websocket with them. I dont know how scalable this soln this, but still.
http://www.html5rocks.com/en/tutorials/workers/basics/
I have a web application that is growing more complex. It makes heavy use of JavaScript based HTML generation and AJAX calls, and herein lies my problem:
Since I can't know how long an ajax call might take getting back to client side, I don't know when the callback gets actually executed. The user might have at that point navigated away from the element that originally caused the AJAX event, in which case this callback can cause some havoc. Is there a way to "expire" old callbacks ?
Are there any libraries that would offer that functionality? (I am using jQuery now but am not 100% familiar with it).
Thanks,
You might want to look into Ajax Queue Manager. There are params you can set to abort old requests before sending a new one. I think that might be what your looking for.
Well, the simple answer is to check for the proper state of your app within your callback functions, before they do whatever it is they are doing that causes problems. For example, you could make sure that certain elements are still being hovered over.
I'm having a problem with a Java JSF application: In a certain case, a user action causes an Ajax HTTP request that updates the UI correctly, but then immediately a second request is triggered, causing a second, incorrect update.
How can I find out (preferably using Firebug) where exactly that second request is triggered? There's a lot of minified framework JS code, so I don't know where to place breakpoints. Setting the form onsubmit handler to console.trace did not help, I suppose because these are independant Ajax requests.
While trying out the suggestions in the answers, I found that Firebug already has exactly what I need out of the box: the Console tab displays all requests, and for Ajax requests it shows the file and line number where they originate, which tells me where to set my breakpoint...
Using Firebug you can set Breakpoints on DOM (HTML) Mutation Events if you have some HTML changes in your UI update.
If the framework abstracts the AJAX requests, you should be able to trace the calls to the abstractions. For example, jQuery allows this through its global AJAX event handlers.
Another, more robust way to tackle the problem would be to replace the XHR object and trace calls made to it (i.e. if the framework does not provide the above abstraction or if the calls that you want to use don't use the abstraction). Just replace the GM_log with console.trace in the script at the end of the page and include it in the page you're testing.
What I personally have done in these case is using an HTTP proxy that can put a request or response 'on hold'. E.g. Burp Proxy (this is actually a security tool, but it works great for debugging purposes)
Start up the proxy and configure your browser to use it. Navigate to the page where the roque requests originates from and activate intercepting requests (this might take some practice as Burp Proxy can be a rather complicated tool).
Now do the user action, if all goes well the proxy intercepts it and waits for your confirmation to let it go through. Do this. Then you'll probably see the second request coming and being intercepted by the proxy as well. Don't let this one through, but instead switch to Firebug and suspend into the debugger. Hopefully you'll then be able to see where it originates from. Edit: on second thoughts, the asynchronous nature of AJAX probably means you won't be able to see what the exact spot is via this method anyway... :(
At least you can also configure it to intercept responses. Both requests and responses can be edited on the fly, which can be great for experimenting and debugging and might help in narrowing down the problem.
Might this would help, caller is a method in Function object of javascript.
console.log(arguments.callee.caller.toString());
I'm creating a web application that allows users to make changes through Javascript. There is not yet any AJAX involved, so those changes to the DOM are being made purely in the user's local browser.
But how can I make those DOM changes occur in the browser of anyone else who is viewing that page at the time? I assume AJAX would be involved here. Perhaps the page could just send the entire, JS-modified source code back to the server and then the other people viewing would receive very frequent AJAX updates?
Screen sharing would obviously be an easy work-around, but I'm interested to know if there's a better way, such as described above.
Thanks!
You are talking about comet, for an easy implementation i'd suggest:
http://www.ape-project.org/
and also check these:
http://meteorserver.org/
http://activemq.apache.org/ajax.html
http://cometdaily.com/maturity.html
and new html5 way of it
http://dev.w3.org/html5/websockets/
Hope these help.
Max,
Ajax will have to be involved. If i may, I'd like to suggest jQuery as a starting point for this (i know you didn't tag as such, but i feel it'd be appropriate, even if only to prototype with). the basic semantics would involve running the ajax request in combination with a setInterval() timer to fire off the ajax request. this could be done in jQuery along the lines of:
$(document).ready(function() {
// run the initial request
GetFreshInfo();
// set the query to run every 15 seconds
setInterval(GetFreshInfo, 1500);
});
function GetFreshInfo(){
// do the ajax get call here (could be a .net or php page etc)
$.get('mypageinfostuff.php', null, function(data){$('#myDivToUpdate').html(data);});
}
that's the basic premise... i.e the webpage is loaded via GetFreshInfo() initially straight away, then it's requeried every 15 seconds. you can add logoc to only refresh the div if there is new data there, rather than always updating the page. as it's ajax, the page won't freeze and the process will be almost invisible to the user (unless you want to flag the changes in any way)
Hope this helps
jim