Why is Firebug hitting non-existent break points? - javascript

I've been using Firebug to debug some javascript I have on one of my pages. Recently it has started hitting non-existent "break points" at seemingly random spots in my javascript. It seems like most of these points are in third party libraries like jQuery, but it also stops on custom javascript.
I'm not seeing any errors at these lines and I definitely don't have break points there. Can anyone think of why Firebug would be stopping here? It's getting to the point where I have to hit the "Continue" button about 20 times to get the page to finish Javascript execution...

I had this problem and fixed it like so:
Uninstall firebug in the firefox add-ons manager
Close firefox
rm -rf profile_folder/firebug
Delete all firebug-related lines from profile_folder/prefs.js
Reinstall firebug
Hope this helps!

There is nothing wrong with firefox, this is happening because you might have enabled auto breakpoints. Check here http://getfirebug.com/wiki/index.php/Script_Panel for more details about what i am talking about. Disable them on console and script panel and everything will be solved.

This question is old, but it is also the top result for searches: like firebug random breakpoints.
In my experience, assuming this is not due to break on exception or other settings, every time this happens to me there is some collision with jQuery, or another library. Sometimes even name spacing does not keep you safe, and this is very hard to debug.
Most recently I had a function named: name_space1.nestedns.focusCursor(). Something was messing with my focusCursor function.. didn’t figure out what, just changed the name.
Farther in the past I had a function or var named ns.companyabreviationToolTip... and there was collision and breaking on this as well. Changed ToolTip to something obscure, and everything was happy. Maybe firebug has a secret break on collision setting. If this is a bug, I hope it does not get fixed… it seems useful.

Related

Chrome Developer Tools keeps breaking where no breakpoints are set

When debugging JavaScript code using Chrome Developer Tools the debugger pauses on code where breakpoints are not set. I don't have the Pause on exceptions feature enabled, and there definitely are not breakpoints set (see attached image).
I asked a similar question before which was helpful but didn't quite solve this issue (previously I had the Pause on exceptions enabled). In the example below I swapped out the minified version of kendo.all.min.js for the unminified version, which allows me to see where the script execution is being paused, but I don't know why it is being paused. This happens a lot with jquery.min.js too.
I fixed my breakpoints problem by clicking the "Restore defaults and reload" button located in the “Settings” section. To find the button: In Developer Tools click the cogged wheel next to the top right three vertical dots. (Note: If using older versions of Google Chrome, click on the top right three vertical dots and then select “Settings F1”). The button “Restore defaults and reload” is at the bottom right.
Also note that it really restores defaults - you lose all previously saved breakpoints and any files you have open in Developer Tools will be closed.
I got this solution from: Chrome javascript debugger breakpoints don't do anything?
Accepted answer to Import/export Chrome devtools breakpoints & settings between computers reminded me to check "devtools-on-devtools" and in the DevTools' inner Application Local Storage remove the faulty element(s) of the JSON list value for key breakpoints to fix my same issue without resetting everything.
Later it happened again, so I wrote this console snippet:
((stores, matchKey, removeMatchingRegExp, dryRun)=>{for(let store of stores){
let r = JSON.parse(localStorage[store]), l = r.length;
r = r.filter(b=>!b[matchKey].match(removeMatchingRegExp));
if(!dryRun) localStorage[store] = JSON.stringify(r);
console.log(`${dryRun ? 'Would' : 'Did'} remove ${l - r.length} entries from ${store}:`, r)}; return 'OK'})
(['breakpoints', 'domBreakpoints'], 'url',
new RegExp('^https?://example.com/script.js$'), true)
Note:
Provided without warranty: Use at own risk. Backup your data.
Edit it - at least the RegExp argument - to suite your needs.
The last-most boolean should be false to disable dryRun.
Outer DevTools must be reopened for effect.
I was able to resolve this by updating Chrome. I don't think the version matters, just the process of updating resets all of the breakpoints that have been stored in the cache.
F8 has two functionalitys. 1. Skip ot next Breakpoint, 2.stop wherever the Browser is executing code. This works even if you have no breakpoint set. For example spamming F8 when you forgot to deactivate breakpoints might cause the browser to stop anywhere.
When you go to the debugger shortcuts you can see that F8 has the functionality to Pause / Continue. But it sadly seems like you can't split them on two different keybinds.
Since I know this feature I never ran into this "bug" anymore.
I'm posting this answer in case it will help someone who, like me, missed an important clue as to the cause of the phantom breakpoint behavior. In my case, it was "user error" --mine. The root cause was a forgotten "debugger;" statement in a JavaScript file that was itself generated from TypeScript. I had removed the debugger; statement from TypeScript locally, run and tested without issue from localhost. But I had pushed the version with the statement to remote and it built and released to our dev site with the statement present. The dev site build excludes the TypeScript source files. When the debugger statement was hit, Chrome tried to load the .ts source and displayed "Could not load content..." I just assumed it was at a breakpoint (I'd set many during testing). And when I saw "No breakpoint" I assumed Chrome was experiencing the issue addressed in this thread. If I'd bothered to look in the Call Stack trace, I would have seen the source code line in the .ts file and pretty quickly figured it out. Here's a screenshot:
just disable the cache and reload the page, the breakpoints will show up again

What can be the reasons for JavaScript breakpoint is not hit?

I set a breakpoint in a script block of a razor view.
VS2012 attaches to IE but breakpoint has yellow triangle with exclamation mark saying:
The breakpoint will not currently be hit. The code in the document is
not loaded.
Script debugging is enabled in Internet Options of IE.
Have no idea what is wrong.
I faced this problem too. After trying many codes and things take from different posts in Stackoverflow and others websites, they have not solve my problem. When i have take a look for #robert4 solution and go back in my javascript code, i saw one error and fixed it, by doing like that, i have finally solve may problem and can now get a breakpoint in my javascript document. For those who will face this type of problem, i think that the first thing to do it is to verify your js file code by code to see if there is no error before beginning to implement each of others solutions take from differents posts.
When I had similar issue it turned out that an omitted } was the cause
(in one of the JavaScripts of the page, one of the {}s was not closed).
There was no error message on the browser console at all,
just didn't work and I had no clue for half an hour.
When I fixed the missing }, everything began to work as expected.

JavaScript breakpoints no longer working in Visual Studio 2008?

My Visual Studio JavaScript breakpoints are no longer working. They don't now. I have tried everything that I could find on the web. the javascript statement debugger dosn't work in FF either (and no, it's not on the first line of the function) debugger does work in IE but I need debug for FF issues. Firebug, IMHO sucks - just look at that watch list you have to wade through. I need the immediate window to check vars ect. I have tried in the latest FF, Chrome and IE. But VS2008 just won't break anywhere in Javascript.
Debugging is enabled everywhere on everything, I have tried attaching to the browsers, deleting temp files, clearing caches, ect, ect, ect, ect, ect. Tried every thing short of a 12 gauge shotgun (I'm saving my shells for the next microsoft employee I come across). The last thing I tried is a repair of VS. Nope, didn't work. I tried a complete VS uninstall, regclean, defrag while I was at it and then a reinstall of VS2008 and SP1. After the reinstall I tried a blank page with 1 button and one 3 line function shown below.
function TestIt() {
var x = 0;
debugger;
alert("In Test function");
}
put the breakpoint on the var x = 0; line. Nope, didn't work.
Microsoft doesn't have any answers, they act like it's the first that they have heard of it. Seems that this issue has been around since vs2003 and people still have this problem in vs2010. Ideas?
I got tired of iffy javascript debuggers and have been heavily using logging instead.
Have you tried Chrome's debugger? I've long since abandoned Firebug in favor of Chrome.

Scroll with no backward with IE

I am using the Mootools Fx.Scroll effect to navigate horizontally through my website sections. Everything is working properly with Firefox, but Internet Explorer gives me some trouble. First the section were a big mess, but after adding one line in the Mootools core file thanks to a lighthouseapp.com patch, the sections are now well displayed.
My problem is that I can not go backward (to the left), only going to the right (again, it is only with IE...). The working demo is here.
After days of unsuccessful research, I am asking for your help, for any advice. I will provide any needed details.
Thanks a lot ;)
erm - couple of things.
you have commented out mootools 1.2.3.1 and gone back to 1.2.1, any reason for this?
you run to patch the framework using some code from the ticketing system, seems rather dubious to me and it most certainly should not be how you approach solving this. I am far from saying that mootools is free of errors but my point is that for such a simple transition, there can be a million other solutions than to look at the framework's ticketing system. all things being equal, it is safe to assume the problem will lie elsewhere... (and yes, I know of an error to do with Fx.Scroll that is still not patched but I don't think it would affect your setup).
for starters, my debugger on IE7 reports a JS exception on line 57 of your code:
if($('prog')) { // error somewhere here.
progBrowser = new ProgBrowser('prog',{
topX: '50px',
topY: '100px',
mouseOnColor: '#ffe400',
mouseOutColor: '#ffffff'
});
}
subsequently, a lot of code breaks and you get an utter mess on your screen. but there is nothing wrong with your instantiation - the problem is elsewhere: you have actually removed methods of the ProgBrowser class and left a trailing comma, check the bottom of the prog-browser.js file
}, // this comma will always break IE.
});
as for the scrolling problem, you can try using element.scrollTo(x,y) - but in any case, you have totally rewritten the normal event handlers for the class (replacing the click event with a onclick assignment etc) - fix the exceptions and post back your error-free page and we can look at doing scrollback again. good luck :)

How to reproduce: Script Error, "Object does not support this property or method."

Can any one give me a scripts (HTML/CSS/Javascript) that can reproduce this error on IE 7.0? I am trying to fix this bug in my page where I get this warning but could not exactly found the problem. Line number does not match with the source either.
I thought the better approach would be to create a bug and then work on it incrementally rather than making some wild guess!
As Shog said, that error will occur when you try to call a method on an object which doesn't have that method.
This is most often caused by an object being null when you expect it to, well, not be null.
var myEl = document.getElementById('myElement');
myEl.appendChild(...)
The above example will cause that error if the "#myElement" element doesn't exist.
If it's only happening on IE and not Firefox, chances are it's because you're using a method which IE doesn't support.
The solution? You can try the Script Debugger, but I've never found that to be useful myself. The most reliable, yet painfully slow method is alert() debugging. At strategic points through your code, put in an alert with a unique message. At some point IE will throw an error, so you'll know that the error is somewhere between the last alert which you saw, and the next one which didn't.
function myFunc() {
alert('a');
var myEl = document.getElementById('myElement');
myEl.appendChild(something);
alert('b');
// more code
}
if you ran that and you saw 'a' but not 'b' you know it's in between there somewhere. This is just the sad state of javascript in IE, I'm afraid.
If you make your code follow the jslint.com rules, it will go away.
It will also point you at exactly where the issue is in your code.
I thought the better approach would be
to create a bug and then work on it
incrementally rather than making some
wild guess!
You would be wrong. There are countless scenarios that could produce the error you are seeing. All it means is that you're trying to call an undefined method. For instance:
var blah = {};
blah.methodWhichDoesntExist(); // <-- error
This could be the result of a typo, an undetected failure in some other component, or gamma rays consistently flipping bits in your HTML right after you save. Hard to be any more specific without knowing more about what you're doing.
For IE, download the Microsoft Script Debugger
I just fixed a similar bug by using IE8 and switching it into IE7 mode. You then get a more specific error message telling you which line of which file is failing.
After that set a breakpoint so that the code stops just before the offending line (F12 to get to debugger tools, then choose the JS file you want from the 'scripts' dropdown and click to the left of the line number. Click 'start debugging' to make it use the breakpoints).
As others have pointed out, this error could have many causes, but in my case, I had two IDs on the same page with one capitalised and one not. getElementById() was getting the wrong one. Only IE7 complained.

Categories

Resources