Where does Firefox store the contents (text messages) of the Error Console. The errors, warnings, messages etc. are stored somewhere as Firefox retains them even if the browser is closed and re-opened.
I tried to search the entire profile folder but couldn't find out which file or sqlite DB these error console messages are written to ?
Does anyone have idea about this ?
Thanks in advance.
No, Error Console is cleared if you close Firefox and re-open it.
Error Console isn't tied to a particular browser window, so while Firefox runs, the messages are retained even if you close and open some windows. During the lifetime of the application, the messages are stored in memory (code link).
If you're looking for a way to dump messages that appear in the Error Console to a file, it's possible to do that, but I don't remember off-hand and don't want to look for it unless that's what you're interested in.
[edit The best I could find was this]
[edit] if you indeed see this, are you sure it's just base Firefox? Maybe it's some of the extensions you've installed? (Though it would be weird to implement messages persistence in the Error Console.)
Related
I cannot figure out how to debug my simple extension. Script (a content script) loads (because the first console.log call shows in the tab's console) but then nothing. There's no error what so ever and no second console.log call.
My question is not about solving my code issue (there surely is one, if only firefox would tell me where), it's about finding the place where warnings/errors about the add-on are in firefox (like 'sdfsdf has no object property ...')
about:debugging is no help, the console it can open shows some errors (example: 'Error: Service "domainInfo" is not available. Make sure it appears in the "requiresServices" property of the module's background where is it used.') that have nothing to do with what I'm trying to do (I can tell from the source and nature of errors)
// start of file
console.log('I AM LOADING');
// simple DOM manipulation code here...
console.log('I AM LOADED');
// end of file
The content scripts are supposed to be debugged with the DevTools instance attached to the web page.
However, as you noticed, the errors in the content script are not reported in the tab's Web Console due to a bug. (As of Firefox 70.)
As a workaround you can:
use try..catch with logging,
check the Browser Console (which does show error in the content script)
use the Debugger's "pause on exceptions" option.
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.
I'm currently developing a firefox extension. I use dump() function. But the messages are not showing up in the console. I've cahnged the value of browser.dom.window.dump.enabled to true in about:config and restarted firefox from command linelike firefox.exe -console. Still i cant see the dump() message. What is possibly wrong?
Btw, Is there any addon which can show the dump() messages without having to restart firefox in command line firefox -console?
Starting Firefox with -console command line switch is only necessary on Windows. If you are using Linux then you should simply start Firefox from a terminal window. On Mac OS X the console messages can be displayed via some application (sorry, don't remember which one). Also, changing browser.dom.window.dump.enabled is only necessary if you are logging from a window-bound context - in JavaScript modules and such it always works regardless of this preference.
If you want to have your logging messages available more easily you should be using Components.utils.reportError() (or nsIConsoleService.logStringMessage() as explained in the documentation) - this will send messages to the usual Error Console that can be opened at any time.
I find this addon to be really helpful when logging errors/messages to the console: https://addons.mozilla.org/en-US/firefox/addon/console%C2%B2/
To finally get the output from dump(), I specified dump file location by creating a preference browser.dom.window.dump.file and setting it in about:config.
I believe I had the same issue. I couldn't get dump() to print to stderr nor the console even though I had set browser.dom.window.dump.enabled to true. I'm on Ubuntu 14.04.
Source:
https://developer.mozilla.org/en-US/docs/Mozilla/Preferences/Preference_reference/browser.dom.window.dump.file
The only error I ever get is SIGABRT in main. This is getting incredibly frustrating as I have to guess what line caused the error and why.
This is a far cry from visual studio's informative error messages. It's basically like sending off an entire novel to an editor and the only notes you get back are: "There is a problem somewhere in your book. There may be many or just one and they are either gramatical or to do with spelling."
I just don't know how anyone can work like this. What am I doing wrong? Surely I'm missing something essential.
Write some NSLog() into your code and you'll see it in the console. It's a great help to narrow down a crash.
if you have encountered memory problems (aka – your app crashes for no apparent reason because you attempted to use an object that you deallocated to soon) setting NSZombieEnabled = YES can help you diagnose the problem.
Normally, when your app crashes in this way and you look at the log it tells you nothing (thanks Apple!). However, if you select your executable (under Executables in Xcode), hit the info button (round blue thing at the top), select arguments and put this in the bottom screen NSZombieEnabled = YES the log will give you more information.
Now, if your app crashes the log will have an indication of the object you attempted to access that has already been deallocated. Not forget to turn it off before you deploy it – you don’t want a bunch of nszombies running around your clients phones…
http://howtomakeiphoneapps.com/nszombie-and-xcode-oh-my/27/
How to change the default Firefox error console buffer size? The problem is that there isn't enough time to read messages: old ones get overridden by the newer messages.
I know this is an old one, but this came up as my top search and the setting can now be found in the about:config settings.
Type about:config into the address bar and select ok to the dragons.
type this into the filter
devtools.hud.loglimit.console
AMO :: DevPrefs
Can increase buffer size from the options panel of that addon:
(source: mozilla.net)
EDIT: There are two parts to this answer. The Console Service has one limit, which applies when the Error Console is closed. The Error Console has another limit, which applies when it is open. Normally these limits are both set to 250.
It is not useful to have the Console Service limit is higher than the Error Console limit, since you need to open the Error Console in order to view the errors, but in theory you can do this by debugging the Firefox executable and setting a breakpoint on xul!nsConsoleService::nsConsoleSerice and set mBufferSize to a larger value. Symbols to allow you to do this are available on the Mozilla symbol server.
You can increase the Error Console limit by editing the consoleBindings.xml file. This file is stored in one of the .jar files provided with Firefox (omni.jar in Firefox 4). Note that editing a .jar file will stop partial updates from working, instead the Firefox updater will reinstall the full updated version.