I am working on a web application with most of the code written in javascript. This application is using backbone.js and It has all kinds of event listeners. Some view functions are listening to model change events, url change events or user interactions. It's really hard to tell how a specific function was called. Is there a way to get the entire trace of function calls that lead to current invocation?
Set a breakpoint at the start of the function in the debugger. When the breakpoint is hit, then examine the callstack in the debugger and you can see the function calls that led to this point.
Firebug for Firefox will show the stack, once it stops in breakpoint you set.
Do you need the stack for debugging purposes?
Or, do you intend to use this information inside your code to make some kind of decision?
If that were the case, you could check the value of the variable "this".
Related
I managed to either trigger bug in one of libraries that I used or I passed invalid data there.
Fine, it happens. But to diagnose what happened it would be nice to know where I actually call this library function! But Firefox "helpfully" truncated stack trace.
How can I get access to a full stack trace?
You could set a breakpoint on the 3537th line of the lunar_assembler.dist.js file. It would allow you to display the full stacktrace (and the initial caller) before the recursion begins.
See https://developer.mozilla.org/en-US/docs/Tools/Debugger/How_to/Set_a_breakpoint
This allows to display a dynamic view of the current stack where you can click on every frame to check every function call, their lexical scopes, the parameters being passed to the subsequent calls, etc...
To set a breakpoint, you can place debugger in the place where you want to stop loading
To get a call stack in the old versions of JS you could use arguments.callee - example
In the strict mode and newer versions, you can use new Error().stack - example - or console.trace() - example
In my application I need to know when a user switches to show his screen instead of camera, both the local user and for other users. When I change to showing the user's screen, MesiboGroupcall_OnVideoSourceChanged is not called. The only listeners that are called is MesiboGroupcall_OnVideo and MesiboGroupcall_OnAudio for the local participant, and no listeners for remote participants.
Inspecting the participant through the console shows that the listener have indeed been set to be my desired function,
MesiboGroupcall_OnVideoSourceChanged: (newVideoSource, oldVideoSource) => {
console.log("MesiboGroupcall_onVideoSourceChanged: newVideoSource:", newVideoSource, "- oldVideoSource:", oldVideoSource);
}
but it won't run. Do anyone have any tips on getting this to work?
From what I can decipher reading mesibo.js, MesiboGroupCall_OnVideoSourceChanged is the only listener that is referenced only twice, when it is declared and when it is set in the call method. It seems like it isn't called elsewhere, for instance I would expect it to be called in to methods that change the video source like .setVideoSource(). I also find no reference to MesiboGroupcall_OnVideoSourceChanged in the source code for the live demo web application, which leads me to suspect that it might not be implemented yet or work correctly. If any mesibo devs read this, maybe they can clarify.
It would also be useful to get information back locally when the user allows or disallows the screensharing, are there any way of doing this with mesibo? I see other video conference providers do this through promises, but I have a hard time seeing if anything similar is available for mesibo, without having more documentation on the mesibo interface.
I thought maybe I can listen for it through the DOM, but haven't looked into doing that yet. If anyone has any experience or thoughts on this, that would also be great.
I am trying to incorporate into my Automation scripts functionality that will prevent the whole script from stopping when an Object Does Not Exist Error for a web object occurs. Instead the script should catch the error and perform a different function and continue running other scripts.
I first tried a Try Catch block, but then I learned it cannot see the errors generated by TestComplete itself. I looked into the Event Handlers you can make via the tool as well, but they don't seem to make any sense for the solution I need.
Here is an example and what I am trying to do.
function TestPage() {
\\Some condition where it will only continue if no errors are raised
var testobj = Aliases.MappedName
testobj.Click
//more code
//goes here if an error occurs at any point
//executes a reset function.
I can suggest two possible approaches that can be used separately or together.
You can check an object for existence before trying to get it. When working with the Name Mapping tree, this can be done with help of the WaitAliasChild and WaitMappedChild methods. This method is the best if you know that an object can be missing at a specific test step.
You can handle the OnLogError event in order to handle errors you want. Using this handler, you can prevent the error from being posted to the test log. Also, you can disable the Stop on error project option to prevent TestComplete from stopping the test on error and stops execution from within the OnLogError event handler using the Runner.Stop method. This approach works if you do not know at which exactly test step the issue can occur.
Personally I prefer the first approach and treat the second situation as an issue in my test or the tested application.
I'm developing an iOS 7 app that has scripting capabilities using JavascriptCore.
I'd like to have a way to pause or completely stop the code currently running on the JSContext. JavascriptCore isn't really well documented so I couldn't find an answer.
I have a few ideas:
Remove from the context the bridge object used to interact with my app and just let any code still running fail.
Getting the JSGlobalContextRef for my JSContext and releasing it using JSGlobalContextRelease and recreating a JSContext to use.
but hopefully there are better ways.
Any help would be appreciated. Thanks!
There actually is an API that allows to stop execution of Javascript code inside of JavascriptCore. Unfortunately though, it is private and thus cannot be used within apps that are to be distributed through the App Store.
The API in question is the JSContextGroupSetExecutionTimeLimit function defined in JSContextRefPrivate. Not only does it allow to specify a timeout for your JS code, but also a callback that will be called regularly to determine whether the execution should be stopped.
You can find more information in my answer to this SO question.
If still relevant, you could create a loop that adds the counter (that is going up after every cycle) and the maximum value of the counter. I assume you can use a second core since it is called javascriptcore. In this second core you can put a function that increases the value of the counter by 10 so it exceeds the max value of the counter and so the code will continue. You don't need a second core if you can call 2 functions at a time.
Otherwise you can store everything under a different name and overwrite the old ones with nothing.
u can use java script timeout callback when on JSContext object is triggered
function myFunction() {
alert('wait is over');
}
<!DOCTYPE html>
<html>
<body>
<button onclick="setTimeout(myFunction, 3000);">Click Me</button>
<!-- In this context im using a simple button to trigger the call back in your case u can triggeer on jscontext-->
</body>
</html>
I am debugging the site with Chrome Developer Tools. If I check "pause on all exceptions", it pauses a few times when the site is loading and points to jquery.min.js(#line). These are only caught exceptions.
How can I track it back to see which function of my code causes the exception in jquery?
Also, should I really spend some time to track it down, if all my scripts function properly?
Thanks
Update. The problem is that I cannot see any of my functions in the call stack - only jquery calls:
Perhaps I can safely ignore these since all the exceptions are handled.
For issues like the one you're dealing with I find the printStackTrace method handy and keep it in my dev toolkit.
http://www.eriwen.com/javascript/js-stack-trace/
In a method where I'm having issues, I'll simply do the following:
var trace = printStackTrace();
console.log(trace);
I hope this might help you out. Good luck.
You can view the call stack in the debugger to see if your code caused the invoked code to throw an exception. Unfortunately, you may see some exceptions that were triggered within code running within a timer. Also, keep in mind that jQuery sometimes does a try..catch to detect browser traits, so you really should only be concerned with unhandled exceptions.