I'm having a problem getting Firebug (and Chrome) to list the javascript files/modules that I've defined and included. I've recently switched from Dojo 1.5 to Dojo 1.9.1 AMD and am including the javascript modules through the require protocol as designed. This had been working fine until just recently when I changed the Dojo configuration's "async:true" to "async:false" in order to support some legacy code that still needs the "dojo.require" to be recognized and supported. Changing the Dojo configuration to "async:false" allowed the "dojo.require" calls to work, but somehow broke the ability of Firebug and Chrome to "see" the loaded javascript modules. I just temporarily switched the config back to "async:true" to verify that Firebug successfully listed the javascript modules so it is definitely the cause of the effect.
The functionality of the JSP pages still appear to behave as expected - so the javascript modules are being included as needed, but when I try to view them and set breakpoints in them from Firebug - they are not listed. If I search for a particular string that appears in one of them, then Firebug will successfully find the javascript code but shows that it is "located" under the heading of something like:
/dojo/1.9.1/dojo/dojo.js.uncompressed.js line 328 > Function line 1 > eval (2)
instead of the actual file/module name. I'm unable to set breakpoints from this view, but if I add a "debugger;" line into the javascript file then Firebug will stop at that location during execution - not an ideal workaround.
Any idea why switching from "async:true" to "async:false" would cause this behavior in Firebug?
Thanks. Any help is appreciated.
You have to add has:{'dojo-firebug': true } to your dojoConfig like this:
<script type="text/javascript">
var dojoConfig = {
has: {
'dojo-firebug': true
}
};
</script>
You can also add it in like this:
<script type="text/javascript"
src="your_dojo_src_path_here"
data-dojo-config="has:{'dojo-firebug':true}">
</script>
Related
Take the following sample of HTML.
<html>
<head>
<script>
var myArr = ['thing1' thing2'];
</script>
</head>
<body>
</body>
</html>
If you're perceptive, you'll notice that I forgot to put a comma between the two array values inside of the script. This will, of course, cause any browser to fail to parse it and the whole script tag will not run. In previous versions of Code, this would be noted with a red underline, but it seems like in recent versions support has moved to plugins. They recommend installing the JSHint plugin to catch some issues, but I have a .jshintrc file in my project directory, with very few entries (to try to use mostly defaults) and while it catches "recommendations", it's still not catching actual syntax issues that break the scripts entirely. I'm also not sure it's doing anything for JavaScript it sees inside of a <script> tag (which I currently use to do quick tests or examples of features). It highlights keywords, but doesn't check syntax or anything.
Is there any configuration I can apply to Code, or my project, to get back this behavior?
The catching of actual syntax issues has been delegated to the Salsa interpreter within Visual Studio. Maybe this is a bug? However, for the other point you made about quick-checking code within script tags, as of the v0.10.10 Feb 2016 release notes:
There is no longer support for IntelliSense in script sections inside HTML documents.
I'm trying to move my workspace to c9 because the Ace editor's autocompletion really pleased me when I worked on NodeJS projects.
But now I would like to work on JS files client-sided. It is from this point autocompletion going wrong. Indeed, there is nothing such as "require" command in client-side JS inside of the JS files themselves (except using some plugins) to inform of the other source files used in.
So when I use, in one of my JS files, a function that is defined in an other file (even libraries, frameworks : jquery, etc), Ace notifies me that the function is not defined (cause it has no way to know that the function is defined in another file, I guess).
Here we go : is there some comment line I could put in my code, or some configuration of c9 I could set, to correct that behavior ?
To remove the errors and warning, you can just add the following line near the top of your javascript file:
/* globals jquery lodash someOtherLibrary */
However, Cloud9 doesn't do autocomplete for client side libraries yet.
Abuse C9's require support
When you use var yourLibrary = require("./somefile.js");, auto-completion works perfectly.
But, as you stated, require() doesn't exist, nor do you want to have yourLibrary set to undefined. (Or to just throw an error)
As it turns out, C9 isn't that smart:
//Your library was defined in some other file
var yourLibrary; //"This does nothing other than making C9 happy
function require() {return 1;} //Define the require function
if(false) {
yourLibrary = require("yourLibraryFile.js");
}
Now, you can use autocomplete (it even shows the documentation comments)!
Note: It doesn't always work.
I would like to use requirejs to manage my code within a firefox xul plugin, and I can't get it to find my modules.
I know that xul doesn't play nice with the data-main attribute, so I have my main.js script as a second script:
<script src="chrome://myPackage/content/require.js" type="application/x-javascript"></script>
<script src="chrome://myPackage/content/main.js" type="application/x-javascript"></script>
This successfully calls the script, and the require function is available within main.js, but when I run
require(['lib1'], function(lib1){
alert(lib1.val1);
})
the alert never gets popped (lib1 is in the same directory as main.js).
I have tried this within and without setting the baseUrl as
require.config({
baseUrl: "chrome://myPackage/content/"
})
and it does not work either way.
Does anyone know how I can get require.js to look in the right place for my modules?
Addendum **
I added an error handling function and the error code returned is
http://requirejs.org/docs/errors.html#timeout
I have loaded the test module into a normal web page successfully. This seems to confirm that the issue is path configuration (it also takes the 15 second timeout before failing)
Firebug seems to have a working requirejs version. But more importantly, they have a far better mini-require.js that will not pollute the shared global scope when used in overlays (if used correctly :p)
https://github.com/firebug/firebug/blob/master/extension/modules/require.js
https://github.com/firebug/firebug/blob/master/extension/modules/mini-require.js
I suggest you have a look at these implementations and also the code using it.
Proactive warning:
Please note, that if your add-on uses code that defines lots of new properties on the scope in overlays (window) either by defining global functions or variables or implicitly declaring variables within functions, then this may interfere with other code running in the same scope (the browser code itself and other add-ons). Besides, should you want to submit your add-on to addons.mozilla.org, then a reviewer might not give it public status if your add-on "pollutes" the global scope/namespace in the main overlay.
Is it possible to find out which javascript files are NOT used on a web page without having to add console logs or debug or removing them to see if things break?
I'm looking for a tool, or a command line script or firefox plugin etc.
For example, let's say I have these included in the header:
<script type="text/javascript" src="js/jquery.js"></script>
<script type="text/javascript" src="js/functions.js"></script>
<script type="text/javascript" src="js/validation.js"></script>
<script type="text/javascript" src="js/something.js"></script>
On the page, calls are only made to functions in functions.js, validation.js and jquery.js. How can I know that something.js is not used and therefore can be safely removed from the header?
I've tried rooting through things like FireBug, chrome's console, yslow and server logs, but these all tell me which scripts have been loaded, i.e. all of them, not which ones have been used.
AFAIK there is no simple "this file is in use / not in use" detection mechanism, because there are so many ways to call, extend and reference things in JavaScript.
There are dozens of ways to call a function, e.g. in the click event of an element, eval() statements... You could be extending the prototype of an existing class in a script file... etc. Also, you could be fetching new markup through AJAX than in turn references functions from a certain include, something impossible to test for automatically without fetching the content.
Unless somebody comes up with a tool that tackles exactly this (I'm not saying it's impossible, just that it is horribly hard) I'd say working this out manually with a good IDE and search function is the best way to go about it.
In answer to my own question getting on for 7 years later, Chrome dev tools now has exactly this feature! https://developers.google.com/web/updates/2017/04/devtools-release-notes#coverage
Only took 7 years :) Also wanted to point out that you can automate this with Navalia: https://github.com/joelgriffith/navalia.
Here's a quick example:
import { Chrome } from 'navalia';
const chrome = new Chrome();
async function checkCoverage() {
await chrome.goto('http://joelgriffith.net/', { coverage: true });
const stats = await chrome.coverage('http://joelgriffith.net/main.bundle.js');
console.log(stats); // Prints { total: 45913, unused: 5572, percentUnused: 0.12135996340905626 }
chrome.done();
}
checkCoverage();
More here https://joelgriffith.github.io/navalia/Chrome/coverage/.
Coming at this from a different direction, you could look into using (lazy) loading javascript libraries. I couldn't say how appropriate this would be in your situation, but I have seen mention of these two in the last week, but haven't used either of them:
http://plugins.jquery.com/project/lazy (only for lazy loading of jQuery plugins?)
http://labjs.com/ (not sure if this does lazy loading?)
I'm working with Dojo and using the "Module Pattern" as described in Mastering Dojo. So far as I can see this pattern is a general, and widely used, JavaScript pattern. My question is: How do we debug our modules?
So far I've not been able to persuade Firebug to show me the source of my module. Firebug seems to show only the dojo eval statement used to execute the factory method. Hence I'm not able to step through my module source. I've tried putting "debugger" statements in my module code, and Firebug seems to halt correctly, but does not show the source.
Contrived example code below. This is just an example of sufficient complexity to make the need for debugging plausible, it's not intended to be useful code.
The page
<!--
Experiments with Debugging
-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>console me</title>
<style type="text/css">
#import "../dojoroot/dojo/resources/dojo.css";
#import "../dojoroot/dijit/themes/tundra/tundra.css";
#import "edf.css";
</style>
<script type="text/javascript" src="../dojoroot/dojo/dojo.js">
</script>
<script type="text/javascript" >
dojo.registerModulePath("mytest", "../../mytest");
dojo.require("mytest.example");
dojo.addOnLoad(function(){
mytest.example.greet();
});
</script>
</head>
<body class="tundra">
<div id="bulletin">
<p>Just Testing</p>
</div>
</body>
</html>
<!-- END: snip1 -->
The java script I'd like to debug
dojo.provide("mytest.example");
dojo.require("dijit.layout.ContentPane");
/**
* define module
*/
(function(){
//define the main program functions...
var example= mytest.example;
example.greet= function(args) {
var bulletin = dojo.byId("bulletin");
console.log("bulletin:" + bulletin);
if ( bulletin) {
var content = new dijit.layout.ContentPane({
id: "dummy",
region: "center"
});
content.setContent('Greetings!');
dojo._destroyElement(bulletin);
dojo.place(content.domNode, dojo.body(), "first");
console.log("greeting done");
} else {
console.error("no bulletin board");
}
}
})();
(Answering this myself because it seems like a common problem whose solution is not well known.)
It seems that one can nicely debug eval-ed code in FireBug provided that dojo does a little cooperating. The trick is to configure dojo to enable such debugging using debugAtAllCosts
<script type="text/javascript" src="/dojoroot/dojo/dojo.js"
djConfig="parseOnLoad: true, debugAtAllCosts: true"></script>
This is described on dojo campus under debugging, which also notes that this setting is not recommended in production for performance reasons and suggests an approach using server-side conditionality to control whether such debugging is enabled.
Also, if you are using a version of Firebug less than 1.7a10 also verify that you have the "Decompile for eval() source" on the scripts drop-down disabled (extensions.firebug.decompileEvals in about:config). When enabled I think this causes Firebug to overwrite the source with its own decompiled version and somehow lose the filename along the way as well.
#peller, This could be why your answer wasn't working for us.
It's disabled by default, but I turned it on at some point and didn't realize it.
It's also being removed completely in 1.7a10 as part of Firebug issue http://code.google.com/p/fbug/issues/detail?id=4035. Also related discussion at https://groups.google.com/d/topic/firebug/y2VR17IFHHI/discussion and https://groups.google.com/d/topic/dojo-interest/nWlZdJDlic8/discussion.
Here's a solution I found for the inability to recurse into dojo.require mudules from reading the NGs.
Change
<script src="dojoroot/dojo/dojo.js" type="text/javascript">
to
<script src="dojoroot/dojo/dojo.js.uncompressed.js" type="text/javascript">
This fixes the less than helpful
undefineddojo._scopeArgs = [undefined];
error that one sees otherwise.
The pattern is essentially xhr+eval... really it's the eval that's the problem... Firefox in particular has no way to track code from an eval back to its original source and instead points at the eval call site, plus whatever line offset there is in the eval buffer. Firebug has implemented a clever scheme to workaround this problem, and added an optional hint which loaders like Dojo can use to embed the original file path in a comment. Webkit now supports this scheme also. It's not perfect, but debugger; and other breakpoints ought to bring you into the correct buffer.
I'm not sure why none of this would be working for you. Which version of Firebug are you using?
djna's debugAtAllCosts solution works for me, for the reasons described at http://dojotdg.zaffra.com/tag/dojorequire/.
However, note that using debugAtAllCosts causes dojo.require to become asynchronous because it uses script inserts rather than xhr+eval. This can cause problems with code that expects dojo.require to be synchronous that isn't brought in using require itself (as described at http://kennethfranqueiro.com/2010/08/dojo-required-reading/). In my case it was testing code I had being run by unit test framework. So the following failed saying that EntityInfo was not defined
var e1 = new EntityInfo();
until I changed it to
dojo.addOnLoad(function() {
var e1 = new EntityInfo();
}
#peller, For me FireBug 1.6.1 will take me to the right eval block but not the right file and line numbers (because its an eval string rather than the original file)..
I'll add one more alternative, use Chrome. It's great for debugging evals (seems to catch some things Firebug doesn't). Do be aware of its issue with caching JS files - http://code.google.com/p/chromium/issues/detail?id=8742.
Personally Firebug is still my main environment, but I am now also using Chrome when things get tricky with evals to get a second view at the problem. Chrome helped me twice yesterday with undefined function/variable issues with the dojo loader that Firebug skipped right past).