如何找出哪个Javascript导致Ajax请求?

时间:2021-01-04 20:58:15

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.

我遇到了Java JSF应用程序的问题:在某种情况下,用户操作会导致Ajax HTTP请求正确更新UI,但随后会立即触发第二个请求,从而导致第二次不正确的更新。

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.

我怎样才能找到(最好使用Firebug)确切触发第二个请求的位置?有很多缩小的框架JS代码,所以我不知道在哪里放置断点。将表单onsubmit处理程序设置为console.trace没有帮助,我想因为这些是独立的Ajax请求。

5 个解决方案

#1


5  

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...

在尝试答案中的建议时,我发现Firebug已经完全具备开箱即用的功能:Console选项卡显示所有请求,对于Ajax请求,它显示它们所在的文件和行号,这告诉我在哪里设置我的断点......

#2


0  

Using Firebug you can set Breakpoints on DOM (HTML) Mutation Events if you have some HTML changes in your UI update.

如果在UI更新中有一些HTML更改,则可以使用Firebug在DOM(HTML)突变事件上设置断点。

#3


0  

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.

如果框架抽象出AJAX请求,您应该能够跟踪对抽象的调用。例如,jQuery允许通过其全局AJAX事件处理程序。

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.

解决问题的另一种更强大的方法是替换XHR对象并跟踪对它的调用(即,如果框架不提供上述抽象或者如果要使用的调用不使用抽象)。只需在页面末尾的脚本中用console.trace替换GM_log,并将其包含在您正在测试的页面中。

#4


0  

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)

在这种情况下,我个人所做的是使用可以将请求或响应置于“保持”状态的HTTP代理。例如。 Burp Proxy(这实际上是一个安全工具,但它适用于调试目的)

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).

启动代理并配置浏览器以使用它。导航到roque请求源自的页面并激活拦截请求(这可能需要一些练习,因为Burp Proxy可能是一个相当复杂的工具)。

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... :(

现在进行用户操作,如果一切顺利,代理会拦截它并等待您的确认让它通过。做这个。然后你可能会看到第二个请求即将被代理拦截。不要让这个通过,而是切换到Firebug并暂停到调试器。希望你能够看到它的起源。编辑:第二个想法,AJAX的异步性质可能意味着你将无法通过这种方法看到确切的位置... :(:

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.

至少你也可以配置它来拦截响应。请求和响应都可以动态编辑,这对于实验和调试非常有用,可能有助于缩小问题范围。

#5


0  

Might this would help, caller is a method in Function object of javascript.

这可能会有所帮助,调用者是javascript的Function对象中的一个方法。

console.log(arguments.callee.caller.toString());

的console.log(arguments.callee.caller.toString());

#1


5  

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...

在尝试答案中的建议时,我发现Firebug已经完全具备开箱即用的功能:Console选项卡显示所有请求,对于Ajax请求,它显示它们所在的文件和行号,这告诉我在哪里设置我的断点......

#2


0  

Using Firebug you can set Breakpoints on DOM (HTML) Mutation Events if you have some HTML changes in your UI update.

如果在UI更新中有一些HTML更改,则可以使用Firebug在DOM(HTML)突变事件上设置断点。

#3


0  

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.

如果框架抽象出AJAX请求,您应该能够跟踪对抽象的调用。例如,jQuery允许通过其全局AJAX事件处理程序。

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.

解决问题的另一种更强大的方法是替换XHR对象并跟踪对它的调用(即,如果框架不提供上述抽象或者如果要使用的调用不使用抽象)。只需在页面末尾的脚本中用console.trace替换GM_log,并将其包含在您正在测试的页面中。

#4


0  

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)

在这种情况下,我个人所做的是使用可以将请求或响应置于“保持”状态的HTTP代理。例如。 Burp Proxy(这实际上是一个安全工具,但它适用于调试目的)

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).

启动代理并配置浏览器以使用它。导航到roque请求源自的页面并激活拦截请求(这可能需要一些练习,因为Burp Proxy可能是一个相当复杂的工具)。

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... :(

现在进行用户操作,如果一切顺利,代理会拦截它并等待您的确认让它通过。做这个。然后你可能会看到第二个请求即将被代理拦截。不要让这个通过,而是切换到Firebug并暂停到调试器。希望你能够看到它的起源。编辑:第二个想法,AJAX的异步性质可能意味着你将无法通过这种方法看到确切的位置... :(:

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.

至少你也可以配置它来拦截响应。请求和响应都可以动态编辑,这对于实验和调试非常有用,可能有助于缩小问题范围。

#5


0  

Might this would help, caller is a method in Function object of javascript.

这可能会有所帮助,调用者是javascript的Function对象中的一个方法。

console.log(arguments.callee.caller.toString());

的console.log(arguments.callee.caller.toString());