I often use gulp and its plugin browser-sync.
Every time i open firebug console tab, i see its full of logs like :
GET http://localhost:3000/browser-sync/socket.io/?EIO=3&transport=polling&t=1457523519574-0 200 OK ۳ms browser...11.1.js (line 2)
I can use clear button but logs are interminable! they will appear twice.is there any persistent way to ride of these(browser-sync) logs?
Yes, there is. Just uncheck the option Show XMLHttpRequests within the Console panel's options menu.
Though note that this will disable the logging for all XMLHttpRequests, (aka AJAX requests).
There is currently no way to filter out specific logs. There are already two enhancements requests for that: issue 4507 and issue 6835 targetting Firebug 2, but as Firebug 3 will be built upon the DevTools, it is probably wiser to follow the DevTools related requests. The closest one to your issue is bug 905978 to filter out messages for blackboxed sources, but I've also filed bug 1102797 some time ago for allowing to blackbox sources from within the Console panel and bug 1255311 right now for ignoring specific log messages.
Related
I'm currently developing a Firefox add-on and I noticed some logging issues in the add-on devtools (for the background script) page. Whenever I'm trying to console.log some object, I don't see any keys or values of this object in the console. There's also no way to "expand" the object like I can in the "regular" (not for an add-on) Firefox browser console.
So, if I e.g. open the add-on devtools and type console.log({ test: "test" }), I only do get "Object { }" as an output:
If I try to log an error I do get a similar result (I can e.g. still log err.message):
try {
throw new Error("");
} catch (err) {
console.log(err);
}
Since I'm currently developing the add-on locally, I'm using web-ext to launch and watch the add-on. web-ext run is essentially launching Firefox without any profile which I thought may explain the difference compared to a regular Firefox browser console.
However, even if I load the add-on in my normal Firefox profile (load temporary add-on), I do see the same behavior for any add-on devtools console.
Is there any setting in the Firefox (add-on) console (or in my preferences) that I can use to log the whole object like it does in the normal Firefox console, e.g. if I open devtools for a regular webpage:
It's hard to tell what's going on without seeing the relevant code for your Firefox add-on, but I have a hunch that this is happening because of reference changes in your script.
In Javascript, an object is actually a reference to a location in memory. So when you run console.log(obj), and that object is modified before you access the console, then it may show up as empty (i.e. because the value being referenced has changed).
I would make sure that the object that you are trying to log is not modified after you log it. If there are any other objects based on the one that you are trying to log, changes to them may also cause your initial object to change as well.
You can try JSON encoding to get around this for logging purposes:
console.log(JSON.parse(JSON.stringify(obj)));
If that's not the issue, then perhaps there's some weird async behavior going on. In that case, you can try logging the object at several other points in your code to see exactly where this behavior starts.
I'm trying to use sw-precache, but I must be doing something wrong!
I'm mostly using the demo code available from the github repo and can't seem to get updates to the app to come through. Once it's cached the first time, it never checks for new versions.
I was expecting that when I publish a new service worker, the browser would request the new service worker and update the cache accordingly in the background. Then using the registration code in the example, I would be able to prompt the user to refresh and get the latest version from their newly refreshed cache.
Would really appreciate if someone could please point me in the right direction.
Example
To demonstrate the problem, I've created an isolated example here:
https://github.com/stevenocchipinti/sw-precache-demo
The example uses a basic skeleton from create-react-app which has a built in build task which take care of fingerprinting the filenames, etc.
I suspect the problem is with me caching everything by using the following sw-precache config:
{
"staticFileGlobs": [ "build/**/*.*" ],
"stripPrefix": "build/"
}
There are more accurate steps in the repo's readme, but the basic steps I'm taking to reproduce the problem are as follows (with my probably incorrect expectations).
Steps and Assumptions
Browse to the app for the first
I should see Content is now available offline! in the console
Reload the page
The message in the console should not appear again because the service worker is installed, but the page should still work.
Go offline and reload the page
The page should still work
Make a visible change to the source code
Rebuild (run the build task and sw-precache)
This is where my understanding must be wrong
Reload the page
The service worker should update the cache in the background
When its done, you should see New or updated content is available. in the console
The actual visible changes should not be visible until the next reload
Reload the page again
The browser will use the new cache this time around
The changes should be visible now!
There shouldn't be any messages in the console
The problem
Once the app has been cached initially, it will never update unless you unregister the service worker or force a reload.
I'm not sure how to make this work - any help would be greatly appreciated!
After replicating your development hosting environment, I can see that you're serving your service-worker.js file with a browser HTTP cache lifetime of one hour:
There's more information as to why this is leading to the behavior you're seeing, along with best practices, in this previous answer. As mentioned at the top of that answer, browsers plan on changing their behavior to stop honoring the HTTP cache for the service worker file by default, mainly due to the type of confusion that you're experiencing here. For the time being, though, the production versions of both Chrome and Firefox continue to honor those headers.
I've entered echo.websocket.org as it was suggested, opened Network tab and WS filter in Chrome Developer Tools, but I do not see any frames. I see connection entries, but Frames tab always stays empty. Is there anything special I should do to see the frames?
Screenshot:
Click Network, WS, select the original HTTP connection and then click the Frames tab. Be aware that the content of this tab may be hidden by another pane, so you need to drag the bar down to see the WebSocket frames.
As of December 10, 2019, the process is slightly different to debug WebSockets with Chrome.
Open Chrome Developer Tools.
Click on the Network tab.
Click on the filter WS (for WebSockets).
Reload the page to make sure you see your connection in the Name column.
Click on Messages.
Now you should see all your communications with your WebSockets, with 3 columns: Data, Length and Time.
Did you send any data on the page? You need to try sending a message after clicking Connect:
There is also a useful area in Chrome where you can view all your active sockets:
You can access it at here: chrome://net-internals/#events&q=type:SOCKET%20is:active
Update:
After seeing your newly added screenshot, it looks like your Data table is squashed up and you need to drag it down to see the entries.
Another gotcha is that in the new Edge the Developer Tools menu option and the Network/WS display looks very similar to Chrome. I forgot I was using Edge and spent 20 minutes trying to find the JSON messages, which I don't think are available in Edge.
There's another way you can have a problem here - if you are using livereload in your development flow.
This (apparently, for me at least) causes multiple instances of the socked to appear, all with empty messages.
It turns out that only the first one is the "real" one, and has messages:
I am writing a search engine plugin for Firefox.
I want to implement search suggestions, so I want my plugin to send requests to my server to get them.
In order to debug this functionality I need to see what requests have been sent and what response is returned.
I noticed that Firebug does not log this info. So I need something else. How can I do that?
The add-on LiveHTTPHeaders works.
https://addons.mozilla.org/en-US/firefox/addon/live-http-headers/
Also try Ctrl+Shift+Q and look at the Network tab, that will probably work, too, although I haven't used that before.
Tools-->Web Developer--->Browser Console(Ctrl+Shift+J)
And in the tab of Net, check "Log Request and Response Bodies"
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