I support not showing console messages from any tabs in the Browser Console since the tabs have their own easy-to-access toolboxes to view the console and that's where one would want to look for messages. My concern is if some messages end up in a black hole due to bad assumptions in filtering and depending on the definition of "content". For example, some security errors from content currently only show in the Browser Console and I wouldn't want those to get lost as they could save a lot of time with debugging: http://output.jsbin.com/hakobezihi/1
Some examples of logging contexts to consider (not specific to CSS): * web extension panel contents * web extension sidebars * bookmarked URL sidebars * the hidden window * frame scripts * process scripts
I don't know which of the above would be affected by parallel CSS parsing.
Overall I agree with the general idea, I just want us to be careful in how it's done to not lose information.
Matthew
On Wed, Apr 11, 2018 at 1:16 PM, Brian Grinstead <bgrin...@mozilla.com> wrote:
> On Apr 11, 2018, at 12:57 PM, Jared Wein <ja...@mozilla.com> wrote:
> I would be perfectly fine with never showing _content_ CSS warnings/errors in the Browser Console.
>
> While we're talking about it, it would be nice if we blocked all content messages (JS/XHR/CSS) from the Browser Console too.
Blocking all content messages will be handled in Bug 1260877. And I suspect it’ll be the default option to only show chrome messages (although we haven’t discussed that in detail yet).
> If not supporting parallel CSS for chrome documents and blocking all content CSS warnings helps you move forward with your goals, that would be fine with me (and make me happier too!). Though I imagine at some point in the future we'll want parallel CSS for chrome documents but I guess we can figure that out at that point.
OK, good to know. I suspect that if we take content CSS warnings off the table then whatever scheme we come up with for the normal console will also be able to work for the Browser Console with warnings coming from the parent process.
Brian
_______________________________________________
firefox-dev mailing list
firef...@mozilla.org
https://mail.mozilla.org/listinfo/firefox-dev
|