with firebug i only knows how to see what ajax-files are called.
i have a jquery mouse click event handler bounded to a link element.
is it possible to see what javascript code is used when clicking on an element in case you forgot if you got an event handler or other javascript code coupled to it?
You can use the profiler in Firebug. Go to the Console tab, and click Profile above the message area, next to Clear. It will say that the profiler is running. Click the Profile button again, and you'll see a report on what functions were called and how much time was spent in each one.
If you're using a library like jQuery, the output may be little less clear since it will show much of the time was spent in functions from the library (i.e. F(), init(), dimension(), etc). It will show which file each function was defined in though, so you can disregard the ones that are in the library (unless that's what you're looking for).
If you're using anonymous functions, you can give them names so they show up in the profiler - see this article for a thorough (possibly too thorough) explanation.
Use breakpoints ..
reference: http://getfirebug.com/javascript
You should take a look at Eventbug (it requires Firefox 3.6, some of the docs are old):
Downloads:
http://getfirebug.com/releases/eventbug/1.5/
Some background:
http://www.softwareishard.com/blog/firebug/eventbug-alpha-released/
Just add 'debugger;' at your onclickevent, and happy debug it.
*Important: you gotta open the firebug panel and Reload the page
Related
Sometimes the .click capybara function doesn't fire and it doesn't fail either because it assumes that it fired. So I looked around and found that .trigger("click") is more reliable with some drawbacks too.
But I read the github for the trigger() function and it says it doesn't work in selenium.
Is there an alternative function for a reliable click with capybara/ruby in selenium?
ex:
find(el).click
vs
find(el).trigger("click")
No, there is no alternative click function in Capybara with selenium (other than potentially executing JS via execute_script). It's not likely the click isn't firing, it's more likely that it is firing at the "wrong" location due to animation on the page causing the calculated location of the click to be out of date by the time the click actually occurs. In that case disabling animation during testing can often help. If it isn't a wrong location issue, and you can create an example that exhibits the behavior, report it to either geckodriver or chromedriver and they will usually fix it pretty quickly (as long as you provide an example that replicates it).
Sometimes, the element you are trying to click is hidden or overlapped, in those cases you have to use-
find(el).trigger("click", visible: false)
Hope that helps.
I have a load of code, and I think much of it is deprecated with numerous methods that are never called. I would like to know which methods in this code will never be called, either as a result of button clicks or via other methods. I could go through and comment out the suspicious methods one-by-one and test the code, but is there a better way?
I am using Visual Studio 2012, and I have tried using JS Lint but that doesn't seem to tell me what I want to know. I really like the Code Analysis for C# and SQL that VS2012 does, but it doesn't do this for Javascript. What should I use?
Open your JS file as the script in a webpage in Chrome. Just surround your JS with an html and script tag:
<html><script>
var mycode = goeshere();
</script></html>
Once you open it in chrome, right click anywhere on the page and click 'Inspect Element'.
Alternatively you can just press CTRL+SHIFT+J to bring up the console.
Once the pane opens, click on the 'Profiles' tab.
Select "Collect JavaScript CPU Profile", and follow the steps to run it.
This will give you timing counts per function call. Try to work through as much of the functionality as you can, then once you are finished look at the function timing counts. Any call with 0 time probably wasn't called. This should at least give you a starting point.
How can I find the specific code that's causing a web page to auto-refresh?
I've looked through the source for an HTML meta-refresh, to no avail. I also can't find any Javascript "reload" in the main page, leading me to think it's perhaps externally loaded through a link javascript file.
How would a "pro" track this down, like through Firebug (or other debugger)?
Note:
I'm more interested in the process of being able to debug and track down something like this, rather than a "catch-all" solution that will stop it cold (such as disabling the Firefox-wide ability for pages to auto-refresh themselves).
The problem is most likely in a javascript file. Go through them looking for the below:
1) Look for anything that can be used to change the URL/location, redirect, or cause browser to go back:
window.location.href
window.history.back(-1)
window.navigate(”example.html”);
self.location=”top.htm”;
top.location=”error.jsp”;
2) Look for timers such as:
setTimeout()
setInterval()
3) Look for broken selectors. You may have click event handlers attached to whole DIVs, or even the whole document by accident.
There is no straightway to find the source of the refresh in javascript. Try #Steve Papa's tips on your code.Incase you want to prevent the refresh and see in the console if you can find any useful info.
To stop the refresh, use onbeforeunload event. The event object passed to the event has lot of info, but I couldnt find anything which points to the trigger. Add a breakpoint on closeIt(e), and look for clues in global variables or call stack(which i dont think will be of much use here).
function closeIt(){
return "Any string value here forces a dialog box to \n" +
"appear before closing the window.";
}
window.onbeforeunload = function(e){
closeIt(e); //add a breakpoint here.
}
setTimeout(function(){location.reload()},2000);
http://jsfiddle.net/Gjuhm/4/
Somehow somewhere in my code one of the elements on the page gets a style attribute which I don't expect it to get. Namely, it gets style="position:fixed". I can see this happening in HTML tab in Firebug, but can't find it in the code. The application is fairly big and I can't simply look through all of the code to find the place, besides, several third-party libraries are being used (jQuery is one of them).
So, my question is, is it possible to somehow catch this style being changed and get the trace?
In Google Chrome, right click on an element in the page and select "Inspect Element." The Developer Tools window or pane will open with that element selected in the source view. You can then right click the selected tag and choose "Break on Attributes Modifications."
Well, after a couple of hours of googling and experimenting, it seems that the best one can do it setup a MutationEvent handler (Firefox supports them) like this:
var node_modified = function(evt) {
if(evt.attrName == 'style') {
alert('Style is changing from ' + evt.prevValue + ' to ' + evt.newValue);
}
}
var test_close = document.getElementById('test_close');
test_close.addEventListener('DOMAttrModified', node_modified, false);
An then set up some kind of logging throughout your code and see when this event gets triggered. Unfortunately, you can't just set up a breakpoint in the mutation event handler and see the stack trace, because event handler's stack trace has no information about the place in the code, where the event got triggered. Kind of logical, but I think that with some hacking this feature can be implemented in Firebug.
Thank you for your time!
In Firebug's HTML inspector you can right click on a node and there is an option to interrupt on attribute change.
Breakpoints persist through page reloads and you can also browse the call stack.
Sounds like you really need a debugger. Firebug has one built in, otherwise you can give Venkman a try, which I find a bit more cumbersome but perhaps is more effective..
Good luck! :)
Is there a way to debug or trace every JavaScript event in Internet Explorer 7?
I have a bug that prevents scrolling after text-selecting, and I have no idea which event or action creates the bug. I really want to see which events are being triggered when I move the mouse for example.
It's too much work to rewire the source and I kind of hoped there was something like a sniffer which shows me all the events that are triggered.
Loop through all elements on the page which have an onXYZ function defined and then add the trace to them:
var allElements = document.all; // Is this right? Anyway, you get the idea.
for (var i in allElements) {
if (typeof allElements[i].onblur == "function") {
var oldFunc = allElements[i].onblur;
allElements[i].onblur = function() {
alert("onblur called");
oldFunc();
};
}
}
You might want to try Visual Studio 2008 and its feature to debug JavaScript code.
If the problem is not specific to Internet Explorer 7 but also occurs in Firefox, then another good way to debug JavaScript code is Firefox and the Firebug add-on which has a JavaScript debugger. Then you can also put console.log statements in the JavaScript code which you can then see the output of in the Console Window in Firebug, instead of using alerts which sometimes mess up the event chain.
#[nickf] - I'm pretty sure document.all is an Internet Explorer specific extension.
You need to attach an event handler, there's no way to just 'watch' the events. A framework like jQuery of the Microsoft Ajax library will easily give you methods to add the event handlers. jQuery is nice because of its selector framework.
Then I use Firebug (Firefox extension) and put in a breakpoint. I find Firebug is a lot easier to set up and tear down than Visual Studio 2008.
Borkdude said:
You might want to try Visual Studio 2008 and its feature to debug JavaScript code.
I've been hacking around event handling multiple times, and in my opinion, although classical stepping debuggers are useful to track long code runs, they're not good in tracking events. Imagine listening to mouse move events and breaking into another application on each event... So in this case, I'd strongly advise logging.
If the problem is not specific to Internet Explorer 7 but also occurs in Firefox, then another good way to debug JavaScript code is Firefox and the Firebug add-on which has a JavaScript debugger.
And there's also Firebug Lite for Internet Explorer. I didn't have a chance to use it, but it exists. :-) The downside of it is that it doesn't a fully-fledged debugger, but it has a window.console object, which is exactly what you need.
It's basic, but you could stick alerts or document.write calls in when you trigger something.
The obvious way would be to set up some alerts for various events something like:
element.onclick = function () { alert('Click event'); }
Otherwise you have a less intrusive option of inserting your alerts into the dom somewhere.
But, seriously consider using a library like jQuery to implement your functionality. Lots of the cross-browser issues are solved problems and you don't need to solve them again. I am not sure exactly of the functionality you are trying to achieve but there are most probably plenty of scrolling and selecting plugins for jQuery you could use.
I am not sure on the exact code (it has been a while since I wrote complex JavaScript code), but you could enumerate through all of the controls on the form and attach an event that outputs something when the event is triggered.
You could even use anonymous functions to wrap the necessary information for identifying which event was triggering.
One thing I like to do is create a bind function in JavaScript (like what you can find in the Prototype library) specifically for events, so that it passes the "event" object along to the bound function. Now, if you were to do this, you could simply throw in a trace call that will be invoked for every handler that uses it. And then remove it when it's not needed. One place. Easy.
However, regardless of how you get the trace statement to be called, you still want to see it. The best strategy is to have a separate pane or window handing the trace calls. Dojo Toolkit has a built-in console that runs in Internet Explorer, and there are other similar things out there. The classic way of doing it is to create a new window and document.write to it.
I recommend attaching a date-time to each trace. Helped me considerably in the past.
Debugging and alerts usually won't help you, because it interrupts the normal event flow.
Matt Berseth has something that may be the kind of thing you're looking for in Debugging ASP.NET AJAX Applications with the Trace Console AjaxControlToolkit Control.
It's based on the Yahoo YUI logger, YUI 2: Logger.
My suggestion is, use FireFox together with FireBug and use the built-in Debug/Trace objects. They are a charm.