Specifically, we've got some external JavaScript tracking code on our sites that throws itself into an infinite loop each time an anchor is clicked on.
We don't maintain the tracking code, so we don't know exactly how it works. Since the code causes the browser to lock up almost immediately, I was wondering if there's anyway to log the results of Firebug's 'profile' functionality to an external file for review?
You should be able to narrow it down by setting breakpoints in the offending JavaScript. It might be messy (especially if they "minify" their JavaScript), but I think it's your best bet.
Perhaps by modifying firebug itself, or creating a firebug plugin, you could log the data to a preferences or sqllite. But firefox doesn't grant write access to plain old javascript.
Related
We use the dojo framework on our websites. A client has called in a panic saying their sales from users of Microsoft Edge have completely dropped off. I've found that in that browser, intermittently, the dojo variable is null after page load. So of course no interaction works for those users, so of course no sales.
But in the course of testing I found this astonishing thing in devtools:
I don't even know how I would do that if I wanted to do it. So I want to track this down but I have no clue what to look for. I might've suspected some weird, recurring setInterval code, but I would not have thought that could get between the two statements on that last console line.
There's a script line just before the </body> tag where I'm able to put a breakpoint. At that point, dojo is set as the framework as expected. So some code that loads after page load is doing it.
(EDIT: I'd be willing to do iterative, brute force breakpoints if I could. But I only have access to Edge via BrowserStack, and trying to set useful breakpoints in minified code is very difficult in Edge's dev tools.)
Does anyone have a suggestion what sort of thing I should look for?
How to debug for this? Is there a client-exposed variable where you can see the functions set to the document's onload, or a way I can put breakpoints in them?
I attempted using a watch() shim in console to watch for the dojo object being changed, but didn't have much luck with that. (but might have done it incorrectly, so if this is an idea, I might need help with proper implementation).
EDIT: There's also this, if this helps make any sense of it. After I delete dojo, setting it works as expected.
Well, I don't know what the specific problem is, but someone has at least given me a way in which this is possible:
window.__defineGetter__('dojo', function(){ return null })
This doesn't exist in the original code, but at least now I see how it's possible at all. The person who gave me this suggests that the code might be trying to get and protect its own copy of dojo, but something about it goes wrong in Edge.
I have a migrated SharePoint application that brought over a bunch of old JavaScript files. One of these files is causing errors in the new environment but I'm unsure of the culprit. They aren't throwing console errors, but rather modifying elements by adding unwanted attributes and classes
Is there a way to prevent the loading of individual .js files without modifying the source? I know blackboxing will prevent the debugger from stepping into the code, but it still loads. If I can narrow it down to one file, I can fix the conflicts that are occurring
Another solution is using Fiddler (http://www.telerik.com/fiddler). It allows you to isolate particular js files and either force them not load, or it allows you to inject your own local JavaScript files on the fly. This way you don't have to migrate your project/solution locally for testing, you can continue to run this on your sharepoint server, and use your own local JS files..
Good luck!!
For the record, this can now be done directly in Chrome Devtools as of version 59.
Load the page, open devtools, then click the network tab. Find the request you'd like to block, right click on it, then select "Block request URL" & reload the page. That resource will be blocked this time around.
Very useful!
Ok, posting this as an answer:
Although intended for other uses, AdBlock Plus can do what you're asking, and it's available for all major browsers.
Just set up a filter like example.com/path/to/your.js and that script should no longer get loaded.
I am in a middle of creating a website where we need to use a lot of script work. But due to extensive data load as we are loading the listing for youtube the browser hangs up due to unresponsive script error.
The data is being loaded using AJAX.
Can any one suggest how to tackle this issue?
Your suggestions will be highly appreciated.
Thanks in advance
J
You can change the dom.max_script_run_time and dom.max_chrome_script_run_time values, but it means the warning comes less often.
The best thing that you can do just find the root of the problem. I think you use Firefox, so if the script runs too slowly and long just click the Stop Script button and go to the error console.
More info are here.
Without knowing details, I can offer only these generalizations. Maybe one or more will help:
The jQuery .ajax call takes an option to make the call synchronous. That, combined with an unresponsive server, would cause the problem you describe. So, make sure you haven't mistakenly set that option.
On some browsers, FF at least, running out of memory causes an unresponsive script error. Chrome has a nice feature in which you can open a new tab, enter "about:memory" into the address bar, and a get a quick overview of how much memory other Chrome tabs/windows are using. See anything outrageous here?
On FF and IE, I have seen an infinite loop cause an unresponsive script error. Use a profiler, to detect this condition.
A profiler, like the one build in to Firebug for example, can help you pin down where in your script the problem is occurring. Knowing that, you can look for opportunities to break up the code into smaller operations. E.g., if you are processing a large amount of data, perhaps you could make a recursive call a setTimeout handler to process chunks of data at a time.
I would like to see what the JavaScript interpreter is doing in real-time, which line it is reading and which function it is running, because I would like to make a full debug on every little piece of the JavaScript to make it faster. For this I need some tool to tell me what the interpreter is doing exactly, if it is defining a variable, if it's running a function, if it's in a loop, check the current intervals (defined in setInterval).
As far as I know Firebug can't do that.
Check out the javascript tab in Firebug, it's a full debugger. Set a break point and when your code hits that line you will have full debugging access to variables etc. Chrome has similar functionality in the developer tools which are included in a standard install.
If you're looking to do automated monitoring/analysis of your program, check out Chrome's Debugger Protocol. It provides a programatic API. I believe (but could be wrong) that this is what tools like Web Inspector and node-inspector are built on.
If you want something more than what the standard Firebug/Web Inspector interfaces are built on, you're going to have to either use something like this or start hacking on the internals of the V8 and Gecko JS interpreters.
As the other answer says,if you want to go step by step, setting a debug point is the way to go.
But since you seem interested in improving performance you might want to consider optimizing only the true bottlenecks in your application. To see which functions take the most to run, and other statistics you might want to take a look at console.profile() (available both in firebug and chrome).
Here is an example:
console.profile('myProfile');
//some code you want to know more about
console.profileEnd();
You can also start it manually by clicking the Profile button in the Console panel(in firebug)/ Profile panel (chrome)
In Chrome you might want to also take a look at Heap Snapshots (they tell you about memory usage).
I've got a little problem with UserScripts in Google Chrome, to be precise with getting to the object window of an iframe. Very doable via the Google Chrome console, very impossible via the UserScript or so it seems so far. To be honest it seems as if it was on purpose, as if there was some reason why I'm not allowed to access other window objects.
document.body.innerHTML += "<iframe name='iframe'></iframe>";
console.log(top.frames.iframe);
console.log(window.frames.iframe);
console.log(unsafeWindow.frames.iframe);
console.log(document.getElementsByName('iframe')[0].contentWindow);
console.log(document.getElementsByName('iframe')[0].contentDocument.defaultView);
-->
chrome-extension://eelclpmekkanegjojjmaldeddncficoj/script.js:14 undefined
chrome-extension://eelclpmekkanegjojjmaldeddncficoj/script.js:15 undefined
chrome-extension://eelclpmekkanegjojjmaldeddncficoj/script.js:16 undefined
chrome-extension://eelclpmekkanegjojjmaldeddncficoj/script.js:17 undefined
chrome-extension://eelclpmekkanegjojjmaldeddncficoj/script.js:18 undefined
Might I ask what Chrome's problem is? I don't really get why should a UserScript have lesser access to javascript than a normal script, what are the implications? By the way, yes, the iframe is on the same domain and protocol. :(
UnsafeWindow isn't support by Chrome, try TamperMonkey, pretty sure it provides read-only access to that variable.
contentWindow.document isn't available for Chrome. contentDocument should work.
Also, XMLHttpRequest for cross domains also aren't supported. Most of these are for security purposes. Userscripts in Chrome are content scripts, they cannot access the functions/variables defined by web pages or by other content scripts. It's mostly for security and isolation of scripts, to prevent scripts from conflicting with each other.
As for document.getElementsByName('iframe')[0].contentWindow, I think it's because the way you're trying to add in your iframe. For starters, don't name your iframe as 'iframe', always a very bad practice.
Instead to attempting to add it into the body's innerHTML, use appendChild(), and append a new iframe object into document.body. Also, instead of document.getElementsByName, try document.body.getElementsByName.
I write greasemonkey scripts for firefox, and Chrome seems too restrictive. And I hope you know about the location hack for userscripts. Check out http://wiki.greasespot.net/Location_hack . You can use Javascript in your userscripts ;) And just to let you know right now, I would VERY much warn against messing with iframes and userscripts. I've wrote a script for Greasemonkey, been trying for 6 months, but somehow, when I involve code inside the iframe, half of the time, that result is undefined, and I never get into that problem with javascript. Also, if you inject .js script objects into a document from a userscripts, the new code is still somehow affected, and so how, randomly, elements show up as undefined. After 6 months of trying, I gave up, and I just have a bookmarklet just injects a .js script into documents manually. Of course, you don't have to do that, you can just use a location hack to inject the code from a userscript. But as for writing entire scripts based on userscripts for iframes, I'm staying far far away...