The Firefox web console (showing Javascript console.log messages) has a search box allowing to 'filter' messages. This is useful to find if a certain message 'foo' has been shown on console, but filtering hides all the other messages on console, so it is not possible to see exactly when 'foo' has been logged.
I would want to 'search' among console messages in order to debug js scripts, to see when a message has been logged and check previous and following messages.
I've searched a lot, but it seems like this feature is not there. There is a way to achieve this result with the native console or some plugin console having this feature?
As you requested, I'll convert my comment to an answer, but leave the comment as is (so people will not be confused).
There is no feature available that allows you to filter for a message and show the last x messages not fitting the criteria. You could, however, enable the timestamp for log messages (top right corner, the settings icon, enable timestamp). Filter your messages, look up the timestamp and remove the filter. I'd suggest using the debugger though.
Related
I use several JS files that I don't have access to and write all over my console.
But I only want to display my own message with console.log("Own message.") and errors (e.g. 404 error).
If I use console.clear before the log function, directly but also all error messages are cleared.
Is there a way to filter console messages to show only errors or the own message and errors?
I have already heard that there are certain libraries for this.
Is it also possible without?
In Chrome, you can just type in the name of your JavaScript file to filter for messages that only come from that file. For example, I had some console messages, and then I typed in userscript to only display logs that came from userscript.html:
Firefox has the same sort of filtering box too.
No need for any libraries.
To display messages from multiple multiple possible sources but no others (for example, to show only messages from foo and bar), use a regular expression, eg:
/foo|bar/
in the same filter box.
Any time you console.log something, on the right side of the console it'll have the origin and line number, like so:
(see index.ts:5).
My app logs things in multiple places, and it would be useful to be able to change what the stack hint is on the right hand side. Right now, for development, they all say DeveloperLoggingUtils.js:55, because that's the file that logs the strings to the console instead of sending them to the server. Is there a way to change it so that it's location is known? For instance, if I'm using my dev logging class in TestButton.js, and calling it in componentDidMount, is there a way to show TestButton.js on the right side?
I have implemented facebook event tracking on my company's website using Google Tag Manager. We want to begin recording the conversion value whenever a user initiates a checkout on our website, and after the checkout is complete.
When testing the code retrieved from an extension (GTM Variable Builder) in Chrome's inspect console tool, it gives the correct output. This tells me that the code is right at least in part, and makes me think that it is executing in the wrong order, or is being overridden.
When I use catch(e) to return a different response in case of error, this provides my chosen output, so I don't believe it is being overridden.
Thinking that the code would work after the page loads, I used (window).load(function). See the following code:
$(window).load(function(){
try{
return new document.querySelectorAll(".container-wrap>.container.main- content>.row>#fws_5dbcb43a4c51c>.col.span_12.dark.left>.vc_col-sm-12.wpb_column.column_container.vc_column_container.col.no-extra-padding.instance-0>.vc_column-inner>.wpb_wrapper>.arv_row>.arv_col.arv_span_9>.arv_rowinfo.clearfix>.arv_desc.arv_row.clearfix>.arv_info.arv_col.arv_span_8.arv_col_last>.arv_extra>#rentalForm>.arv_calcrow.clearfix>.arv_calcrow_p")[3].innerText.match(/^.{1}(.*).{0}/i)[1].trim();}
catch(e) {
return "Well at least you tried";
}
})
The string of code still returns 'undefined'. I expect it to provide the value that this string of code points to when the page is already loaded.
I am currently trying to get the error code from a Video.js error. I know how to get the error Message but I can't figure out how to get the numeric code for the error.
According to the documentation for MediaError there is a status property which is an array (at the bottom of the page). So it could contain multiple codes.
status: Array
An optional status code that can be set by plugins to allow even more detail about the error. For example a plugin might provide a specific HTTP status code and an error message for that code. Then when the plugin gets that error this class will know how to display an error message for it. This allows a custom message to show up on the Player error overlay.
So there's no guarantee there will even be a status code, the status array could be empty. However, you can check the length of the array to see if there are entries, then loop over them looking to see if they contain the status code(s) you're concerned with.
In our web-application, we use the XHR.getAllResponseHeaders()-function to fetch the header field names. We use the X-Access-Token to receive a JWT-token which we sent in the next request to keep session. Since today, after login in, each next request resulted in a redirect back to the login page.
Strangely enough, it was only Chrome having this problem, not Firefox or Safari. And it was only on my pc, because my colleague could still login while I couldn't.
We use the same software, some javascript, same everything, so we noted it has to be something with my browser. Tried a re-instal and disabling some plugins, but that didn't matter anything.
I looks like the XHR.getAllResponseHeaders() function returns the wrong values, although we send the right ones from the server... Anyone an idea why it isn't working anymore?
After a lot of searching, debugging, testing and a lot of frustration we finally found out that the header field names in Chrome 60 where converted lowercase, in contract to Chrome 59 (on the pc of my colleague) where the names remained untouched. So the header field name was now x-access-token instead of X-Access-Token
For those who're using the XHR.getAllResponseHeaders()-function in their javascript somewhere, and are using Chrome, or their clients: Be prepared to have to patch your javascript in order to keep thing working, because since Chrome 60, the XHR.getAllResponseHeaders()-function now only output lowercase header field names!
Some guy with the same problem:
https://twitter.com/thegecko/status/890346862875742210
#thegecko: Argg! #Chrome 60 forcing header names to be lowercase in XHR.getAllResponseHeaders() has broken me!
See also:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/_oxlCPNsrck, https://github.com/whatwg/xhr/issues/146 and the changelog at https://chromium.googlesource.com/chromium/src/+/99c274ae8e7d366261dcfb89e0b98e733fb9d5f4
Based on the discussion in the github and google groups, we were alerted that it's probably a bad thing to execute case-sensitive string compares. In the upcomming HTTP/2, all headers will be lowercase. Because of this, the XHR-specification changed to lowercase all their headers also in HTTP/1.1. Chrome (60) is the first one who changed this, but patches for Gecko/Firefox (https://bugzilla.mozilla.org/show_bug.cgi?id=1370485) and Webkit/Safari are already avaialble...
We tested things out with some simple code, but when sending the header Foo: Bar from our server, the output of XHR.getAllResponseHeaders()-function (in Chrome 60) will be `foo: Bar.
So, in order to get it working in all browsers and be future-proof: Make sure to execute a case-insensitive compare on the header field names from the response. This can be done very easily by using XHR.getAllResponseHeaders().toLowerCase() before handling the headers or by using a case-insensitive regexp like XHR.getAllResponseHeaders().match(/foo/i); to find them.
Edit: After more testing... we found out that using the XHR.getResponseHeader() is also a safe way of getting values from the header ofthe request. Based on the example above, when sending the header Foo: Bar, it doesn't matter if we use XHR.getResponseHeader('Foo') or XHR.getResponseHeader('foo'), both will output the value 'Bar'.
The MDN documentation for XHR.getResponseHeader confirms this:
The search for the header name is case-insensitive.