There seem to be a lot of postings about this class of problems. Perhaps there is a Mozilla forum where I can ask about this, instead of here?
In my case, I can set breakpoints easily and I can see that they are set. But they are not hit when I refresh the page. Instead, an exception I throw (occurring after the breakpoint) is caught.
EDIT: I found an obscure icon near the top of the window to activate and deactivate the breakpoints! I enabled the breakpoints, but now the page is infinitely looping in some of the debugger's own code and reporting "Paused on exception SyntaxError: '*,:x' is not a valid selector."
I was using the debugger for a Web Extension. Did that put it in a strange mode for regular debugging? How would I get out of this mode?
Question Firefox debugger breakpoint not working did not help me.
This is an old post, but I recently had the same issue and decided to share my solution with the world.
I'm on Firefox 89.0.2 and recently noticed that the debugger does not stop at breakpoints. Completely removing my profile directory and restarting Firefox solved the issue.
To find out the location of your profile folder check the following page from Mozilla: https://support.mozilla.org/en-US/kb/profiles-where-firefox-stores-user-data
Related
I am getting a little desperate here: Almost every time I try to use the Firefox browser tools (FF 66.0.3 on Mac, but has been the same in previous versions) to inspect an element, when selecting any page element to show its code in the inspector, the inspector switches to the javascript debugger, marks an error in the jquery.min.js file (complete first line of three) and causes the browser to hang, i.e. I can still scroll the window, but more or less nothing else (for example no reload, no clicking a link would work etc.)
The debugger shows Error: Permission denied to access property "nodeName". I am doing nothing special, I just use the inspector and try to select any element on the page.
The crazy thing is that this happens on most websites, even here on Stackoverflow, so I suppose some particular browser setting must cause this.
I know this is a vague description and therefore a bit off-topic, but I'd be very grateful for any hints how I could fix this.
You most probably have the "Pause on exceptions" and "Pause on caught exceptions" options set to on:
These will cause the debugger to pause javascript execution whenever an exception is thrown, even though the exception has been caught e.g by a try catch block, like many test codes use.
You can un-toggle these to enjoy a more natural experience or click the play icon to resume the javascript.
I can't remember the last time I had Firebug completely working, but I now have a strong need for it. I'm trying to catch some particularly deceptive JavaScript errors using console debugging and debugger; statements.
For one thing, both Chrome and IE are very easily able to stop upon any JavaScript error - either inside a try/catch, or not. With Firebug, in no unusual circumstances does it simply print the error to the console and continue on. The pause icon on the Console tab is already enabled (tried in both states).
Furthermore, the debugger; statement doesn't do a thing - Firebug completely ignores it in any circumstance.
I can add breakpoints to code files, though that doesn't help my situation. At the moment, even IE10's debugging tools are far more useful to me. I've tried reinstalling Firebug, resetting my settings, and even reverting back to Firebug version 1.11.1. Does anyone have any suggestions?
I'm currently (trying) to develop an app with Worklight Studio 5.0.6 and Dojo (Mobile) 1.8.3. I have a really hard time to to find a proper method for debugging. After waiting 5-10 minutes for the build an deploy-process on the server, an error usually looks like this in the Chrome debugger:
How am I supposed to track down this error in MY source? The whole stack trace consists entirely of Dojo code which generates an absolutely useless error message after 20 abstraction layers.
Seriously, how do you guys handle this in real life? What methods do you use for debugging Dojo-driven apps in the browser?
spyro
For dojo.parse errors, I find it useful to pause the Chrome debugger on all exceptions (the purple icon on your screenshot, should be blue). You usally get more details about the cause of the error, the name of the DOM node being parsed, etc. in the first exception being raised.
Rémi.
Debugging dojo based application should be the same as debugging any javascript application.
Usually I will follow these steps:
add console.log() somewhere in code: this is fast and most of time this is enough.
set breakpoint in debugger: if step 1 is not enough, you can base on error information to set breakpoint before error line, then step in or step out.
comment out recently changes: for some error which is hard to find the error line, for example, parse error in your case, the good way is comment out your recently changes one by one till back to your last working version. Or, return to your last working version, then add code back one by one.
Create a simple application to reproduce the error : if your application is very complicate and it is hard for you to follow above methods, you can try to create a new application which mimics your current application but with simple logics and try to reproduce the error.
Based on experience : Some errors, for example, extra ',' in the end of array which works at chrome and firefox, will report a nonsense error information at IE. Debug these kinds of errors is very difficult, you can base on your experience or do a google search.
Did you provide isDebug: true in your dojoConfig? Also, try to see if the same occurs in other browsers.
Update: I recently discovered that there are issues with Google Chrome and Dojo debugging and I think it has to do with the asynchronous loading of files. As you can see in the provided screenshot of #spyro, the ReferenceError object is blank (which you can notice because of the empty brackets {}). If you want to solve that, reopen the console of Google Chrome, (for example by tapping F12 twice). After reopening the ReferenceError should not be empty anymore and now you can expand that object by using the arrow next to it and get a more detailed message about what failed.
Usually what I do in situations like that is to place a breakpoint inside the error callback (line 3398 in your case) and then look into the error variable ("e").
I am not sure how familiar you are with the Web Inspector, but once you hit the breakpoint open the Web Inspector 'console' and check for the error properties "e.message" and "e.stack" (just type in "e.message " in the console).
Also, during development it is better to avoid Dojo optimization / minification, which greatly improve your debug-ability.
Bottom line is to try to place the breakpoint before the error is thrown.
How do I know which part of JavaScript that is executed when some event is occurred in Mozilla Firefox?
This is a very broad question but I'll take a shot. I was a bit curious about the now native debugger in Firefox so I looked into this for you. Firebug is still a nice tool but you don't need it for debugging if you're running Firefox 19 or later. Let me also suggest trying Chrome's DevTools, they are my personal favorite.
To use the native debugger in Firefox, there's two options you will need to configure. Go to about:config (paste that in the address bar). Proceed past the warning. Update the following settings to be true (search is your friend):
devtools.chrome.enabled: true
devtools.debugger.remote-enabled: true
You need to do that so you can set breakpoints in the code. Now load the debugger, the shortcut is Ctrl+Shift+S.
At this point you need to have some idea where to set your breakpoints. If you wrote the JavaScript, you shouldn't have much trouble. If you're inspecting 3rd party code, you might need to browse the source code to get an idea where to begin.
With the debugger loaded, select a source file in the dropdown. It could be a JavaScript file, or any other resource that has JavaScript. You should open whichever file you're interested in inspecting.
To add a breakpoint, click to the left of the line number. You can also right-click on a given line and select "Add breakpoint." If you are debugging something that happens on page load, refresh the page. If it's an event handler, interact with the page to fire the event.
Those are the basics you'll need to get started with debugging in Firefox. Here are some resources you might need to go further.
MDN article: Debugging JavaScript
YouTube video using FireBug: Firebug DebuggingIntro
Chrome DevTools: Breakpoints in Chrome
I hope that helps!
I am using a dedicated test SL web application that hosts SL object I am debugging.
I am debugging using basic F5 and use browser Google Chrome. Sometimes a bug happens, how I reproduce it.
I was running build->debug like 100 times already, but then I made a mistake that caused StackOverflowException and happened in main page constructor and afterwards when I rebuild and hit F5 it says no symbols have been loaded. Note that NOTHING has changed , I use the same 2 buttons combinations rebuild solution-> start debugging.
In order for debug to continue to attach I need to close XAML main page , open it again (in visual stuido) and hit rebuild ->f5 again, afterwards it works fine. (found this solution after SOME time)
I am not sure whats bugged but it appears to be a bug somewhere in SL to me.
Question is - whats going on maybe someone can explain.
This sounds more like Chrome's isolation mode for plug-ins. Generally speaking it's best to manually attach to the Chrome process that is running Silverlight (which isn't always one VS attaches to when pressing F5).
Actually error was super simple, I wasn't understanding how "exactly" xap works, it was a little more magical to me than it is. I just needed to rebuild & clear cache in browser ( chrome in this case) to attach successfully. For some reason I thought that local version doesn't require clear cache call.
Actually chrome is pretty bad to debug silverlight so I recommend IE for this sole purpose, sometimes debugger simply fails to attach to chrome, in that case you usually need to do this by attach to process - choose chrome with silverlight name there.