This is an interesting idea, but do note that libraries can also have errors that cause the web apps to break. Hiding errors would cause confusion. If we do this, we should be extra-careful about how we can avoid user confusion.
Maybe we can add a fourth menu item in the JS menu to show errors from blackboxed sources too, which will be disabled by default ?
Blackboxing depends on running code in debug mode, which is something the web console doesn't force upon pages. At a minimum, implementing this would require a SpiderMonkey hook to notify when en error or warning is about to be logged.
In particular it would be helpful to be able to configure which types of warnings are excluded from black-boxed code. It would be helpful to be able to choose not to show Deprecated / Obsolete warnings, for instance the following error in an old jQuery: KeyboardEvent.key value "Down" is obsolete and will be renamed to "ArrowDown". For more help https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent.key Is something which I do not need to know from a black-boxed source, however other warnings may be desirable.
I agree with Mihai in Comment 1, and I don't think it's best to disable logs from blackboxed sources. Surely if there are errors or warnings causing a problem with your application you'd want to see what is going on and not have it fail silently. In fact, there is a use case for blackboxing a file with a helper function where you wrap console.logs to be able to see the original call location - see https://gist.github.com/paulirish/c307a5a585ddbcc17242. Unfortunately we aren't yet using the correct source links in the console even after blackboxing log-helper.js at http://plnkr.co/edit/3wg4u9HUGXfFH0U7MR7j?p=preview.
Whiteboard: [console-papercuts] → [console-papercuts][devedition-40]
Whiteboard: [console-papercuts][devedition-40] → [console-papercuts][polish-backlog]
Summary: Do not show in console warnings and errors for js black boxed → Do not show in console warnings and errors for black boxed scripts
(In reply to Brian Grinstead [:bgrins] from comment #8) > I agree with Mihai in Comment 1, and I don't think it's best to disable logs > from blackboxed sources. Surely if there are errors or warnings causing a > problem with your application you'd want to see what is going on and not > have it fail silently. For that case, there may be a note shown at the top of the panel telling the user that errors happened in blackboxed sources and maybe give them the opportunity right there to un-blackbox them. Sebastian
The idea of Sebastian seems very good, there could be a 'blackbox errors counter' that can be used to show / hide them.
Maybe this can be added as a negative expression to filter console log by source (that currently it only filter messages that exist) like a simple search text and if found don't show it. For example, writing the filter expression "!source:jquery.min.js" you filter out messages from the jquery source file. Or the other way with "source:myweblogic.js" you only filter messages from myweblogic.js.
(In reply to PhoneixSegovia from comment #11) > Maybe this can be added as a negative expression to filter console log by > source Good idea, though that rather fits to bug 1307883. This issue here is really about filtering out messages coming from scripts that are black boxed within the debugger. Sebastian
(In reply to Sebastian Zartner [:sebo] from comment #12) > (In reply to PhoneixSegovia from comment #11) > > Maybe this can be added as a negative expression to filter console log by > > source > > Good idea, though that rather fits to bug 1307883. Having said that, I'm not sure whether that bug covers both, the toggle options and the text filter. Sebastian
This is a really nice idea, but there's a lot of UX and UI to figure out : - How do we show important logs from blackboxed script (e.g. exceptions in Library code) - How we manage these blackboxed sources, i.e. how to add/remove them - How to sync with the debugger I think that custom filters in the text input, even if attractive might not scale well, and aren't discoverable. I'd rather have a context menu entry on the location (and/or an icon next to it), to silence a file (or just a given call site) This also could be integrated in a broader UI which would show you all the file which initiated at least one log and be able to focus or silence one (could be a left sidebar, like in the debugger).
(In reply to Nicolas Chevobbe [:nchevobbe] from comment #15) > This is a really nice idea, but there's a lot of UX and UI to figure out : > - How do we show important logs from blackboxed script (e.g. exceptions in > Library code) See comment 9. > - How we manage these blackboxed sources, i.e. how to add/remove them That's covered in bug 1102797 and partly in comment 9. > - How to sync with the debugger Sources that are blackboxed within the Console should also be blackboxed within the Debugger and vice versa. > This also could be integrated in a broader UI which would show you all the > file which initiated at least one log and be able to focus or silence one > (could be a left sidebar, like in the debugger). Sounds good to me. Should be done in a separate bug, though. Let's keep this simple. Sebastian
You need to log in before you can comment on or make changes to this bug.