How can I find out which Javascript causes an Ajax request? - javascript

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());

Related

ajax onkeyup event 501 from rapid input

On the Javascript side of things I registered an event listener to a text <input> for the onkeyup event.
Each time the event is triggered, a function is invoked that creates an xmlhttprequest object that passes the input's value as an url encoded POST variable to the request.
The request page is an aspx script which accepts the post variable, does some processing on it, and adds the processed input as a parameter to a MS SQL query. The result set produced from executing the query is placed into a dataset which is converted to XML and then transformed via an XSLT into XHTML that is then inserted into the page that made the ajax call via the innerHTML injection method.
If you've followed me so far, the result is a full-text search on an MS SQL DB that produces results for each key release. It is also worth mentioning that I am using MS SQL 2005 and IIS6.0.
The system seems to work great, except for one test-case. That is when someone just pounds input as fast as they possibly can the server eventually returns 501 internal server errors for each request. After a few minutes, it seems to "fix" itself and operate normally again. I was unable to gleam any useful information from IIS about these internal errors.
Now this is mere speculation, but my first assumptions were that either there were too many open simultaneous requests that had not yet finished, or that there were too many requests being made in a short period.
My initial thought was to create a queue of these xmlhttprequests and only open one at a time.
However, rather than the queue I tried this:
Each onkeyup:
Call abort on the last xmlhttprequest that was generated by onkeyup
Create a new xmlhttprequest for this onkeyup
This procedure appears to eliminate the problem.
What I was unable to do was determine the root cause of this issue: is it a server limitation? or is it a browser limitation? Is there some other way to solve this problem without needing this abort procedure?
I can post code if necessary, but the code is very lengthy and many technologies are at use in this project so I'm not sure if it would really help anyone answer this question.
You may want to look at debouncing.
http://ajaxian.com/archives/debounce-your-javascript-functions

How can I track AJAX calls and determine whether calling the callback function is no longer necessary?

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.

Is it possible to complete the loop from browser->java->c++->java->browser?

I've got a question about data flow that is summarized best by the image below:
I've got the data path from the UI (WaveMaker) down to the hardware working perfectly. The question I have is whether I'm missing something in the connection from the Java Service to Wavemaker.
I'm trying to provide information back to Wavemaker from the HW. The specifics of shared memory and semaphore signaling are worked out already. Where I'm running into a problem is how to get the data from the Java Service back to WaveMaker, when it hasn't specifically requested it. My plan was to generate events when the Java Service returned, but another engineer here insists that it won't work, since there's no direct call from Wavemaker and we don't want to poll.
What I proposed was to call the function after the page loaded, allow the blocking to occur at the .so level, as shown below, and then handle the return string when the call returned. We would then call the function again. That has the serious flaw of blocking out interaction with the user interface.
Another option put forth would be to use a hidden control, somehow pass it into Java, and invoke an event on it from Java, which could then be made to execute a script to update the UI with the HW response. That keeps the option of using threads alive, and possibly resolves the issue. Is there some more elementary way of getting information from Java->JavaScript->UI without it having been asked for?

How can live search / search suggestions be implemented using Dojo?

I want to implement a 'live search' or 'search suggestions' feature in a web application that uses the Dojo Framework. It would be similar to the way Google and Bing searches display matches as you type: when you type in the search box, a list of potential matches appears below. Searches would be performed server side, with the results sent back to the browser using AJAX.
Does anyone know of a good way to implement this using Dojo?
Here are some potential options:
The built-in widget dijit.form.ComboBox
This has very similar functionality, but I've only seen it used with limited data sets. The examples always use small lists (such as the 50 states in USA) and preload the entire data set for client-side filtering. However I presume I could hook it up to a dojox.data.JsonQueryRestStore for server-side search — can anyone confirm whether that works?
QueryBox http://marumushi.com/code/querybox/
This implementation mainly does the job, but it has some minor bugs and doesn't look like it's being maintained. I'd have to do some bugfixes on the code before using it.
Medryx http://blog.medryx.org/2008/09/10/dijitsearch-part-2/
This also looks like it does the job, but it is described as 'alpha-level' code and the link to the code seems to be broken...
I could probably make one of the above work, but I'd like to know if there are any better alternatives out there.
I implemented it 5 years ago when Dojo was at 0.2:
http://www.lazutkin.com/blog/2005/12/23/live-filtering/
While the code is ancient, it is trivial, and hopefully it'll give you ideas on how to attack it. The rough sketch:
Attach an event handler to your input box, which is triggered on changes — use "onkeyup" to detect a change in the input box.
Wait until user stopped typing by setting a timer in your event handler, if it is not set yet. 200-500ms are good waiting times.
The timeout plays a dual role:
It throttles our requests to a server to prevent overloading.
It plays on our perception of time and our typing habits.
If our timeout is up, and we don't wait for a server ⇒ send server a string we have so far.
If we are still waiting for a server, cancel the request and ask again.
This part is app-specific: we don't want to overload a server, and sometimes a server cannot handle broken connections well.
In the example I don't cancel the XHR call, but wait it to finish first before submitting new request.
Server responds with relevant results, which are promptly shown.
In the blog post I implemented it as a widget. Obviously the exact packaging is up to you.

onBeforeUnload - how to call a server-side function without ajax

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&param2=value2" />
From the server side just return an empty image.
You're probably going to need to hook a synchronous call rather than AsynchronousJAX.

Categories