google-chrome-devtools

I'm trying to debug my Chrome extension using console.log("message"); My extension works fine (for the most part), I'm clicking buttons that call function which perform something. Every function as a consloe.log() debug line. If I open the chrome console (ctrl + shift + i) after chrome loads, it remains empty, no matter what I do. Chrome is set to developer mode. Make sure that you are opening the correct dev console. You need to go to the generated background page for the background page console and right click -> inspect popup for the popup console. There was an answer to a similar question

Sometimes when I Inspect Element in Google Chrome I find that I have some large frames, but they are filled with white space. Anyone know what often causes such large amounts of empty space? I have seen timers cause issues with extending the frames length but in the example below I am unsure why a frame would be so large. Would love some help minimizing these This is documented here , see the 'About clear or light-gray frames' section. 'Clear frames' in question are described there as Idle time between display refresh cycles. According to this video , clear bar indicates browser waiting for a

Is there a way to hide the "XHR finished loading" messages in the console? Yes, open the contextmenu in the console, and remove the check at Log XMLHttpRequests . You can still inspect the network traffic at the Network tab. There is some workaround posted in chromium issue tracker http://code.google.com/p/chromium/issues/detail?id=15472 Which version of chrome you are using? In my console there is checkbox to enable or diable log XMLHTTPRequests I am using 17.0.963.79 来源： https://stackoverflow.com/questions/10041468/when-loading-external-data-console-says-xhr-finished-loading

I'm building a front-end in angular that is accessing a flask/python RESTful API. I'm using AngularJS v1.2.16. For some reason, it takes an insane amount of time before the REST resource is loaded, with most of the time just waiting. It's my understanding that 'waiting' is measuring the time to first byte - all my services run locally (the frontend, API and database). Given that the services all run locally, I am at a loss how to debug this. Does anybody have any tips on where to look? I checked all my methods and they run decently fast (under 100ms per REST call). When I use postman , the API

While debugging my app with 'Profiles' in DevTools I found "Detached DOM tree's" accumulating. These detached nodes have retaining tree consisting mostly of checkContext functions (coming from sizzle inside jQuery - v1.10.1). I'm not sure how to proceed with this. What does this result mean? This is actually a bug, there's no reason that Sizzle needs to hang onto the context node, it's only doing it because it's not cleaning up after setting a temporary variable. I filed an issue for it , fixed it, ran all the Sizzle tests, and did a pull request. If you want to patch your existing copy of

I have a remote webpage that loads a remote JavaScript file called script.js . I don't have immediate access to the remote filesystem to make changes to test something. So I copy script.js to my local drive, and in Chrome Dev Tools I add my local folder to the workspace. Then I right-click on my remote script.js file and pick Map to File System Resource... . I pick my local script.js . So now I would expect my locale changes to script.js to override the remote script.js , right? This way I can make some changes to my local script.js and when I reload the page I can see the changes being

Ever since Chrome updated itself to version 32, I have been experiencing aggravating bugs. One of the worst is when editing the DOM using the Web Inspector, and Chrome will about every minute start popping up this dialog, which yanks focus from the Web Inspector: It's complaining about the Web Inspector itself being "unresponsive", when it really isn't, and nothing's gone wrong. This particular page I'm messing with is making use of the mutation-summary library. Perhaps the bug in Chrome that thinks stuff is unresponsive could be related to setting various continuously-running setTimeouts. I