Can we disable CSS warnings in the Browser Console?

[Brian Grinstead]

The console has a ‘CSS’ filter option that shows CSS warnings / errors. It’s off by default, but when you flip it on you will see warnings like "Unknown property ‘user-select’. Declaration dropped.”. The problem is that we pay a perf penalty for reporting the errors, and they aren’t shown by default. There’s a plan in Bug 1452143 to change that so we would only start reporting the errors once the filter is toggled, but dealing with the Browser Console will require extra work since it’s receiving messages from all windows (including those in the content processes)

The main options I thought of for dealing with this are:
(1) Loop through all the windows when the filter is toggled and reparse all stylesheets to trigger errors that happened before we were reporting them. We could simplify this by never showing CSS warnings for content pages in the Browser Console.
(2) Remove the button entirely and just not ever show any CSS warnings in the Browser Console
(3) Allow you to press the button but don't attempt to dynamically begin showing errors. Instead send a message to the Browser Console saying 'restart your browser to start seeing css warnings’

If you use this feature and find it valuable, please let me know. I’d prefer to go with (2) if people aren’t getting value out of it. I don’t have them on myself because it causes a huge amount of noise (you see all warnings from all pages plus the parent process).

Thanks,
Brian
_______________________________________________
firefox-dev mailing list
firef...@mozilla.org
https://mail.mozilla.org/listinfo/firefox-dev

[Dan Mosedale]

Because it's so noisy, presumably in the current form people aren't getting a lot of use out of them.  However, I suspect that could change substantially if we stopped showing content CSS errors in the browser console.  So it seems a bit hard to evaluate the usefulness without doing that first.

Dan

[Jared Wein]

I agree with Dan. https://bugzilla.mozilla.org/show_bug.cgi?id=1260877 looked close to landing a month ago then I think work stalled?

- Jared

[Brian Grinstead]

The content filtering in the Browser Console is pretty close - we have one more platform bug in progress to detect messages coming from chrome contexts and then a relatively small piece of frontend work.

It sounds like you’d be OK with not ever seeing CSS warnings from content pages in the BC, and that you may or may not care about CSS warnings from the parent process but don’t know yet until we can filter out content messages. Would you care if turning on CSS warnings in the parent process didn’t show ‘past’ CSS warnings but started showing only new ones?

Brian

[Jared Wein]

Doing so would make it impossible to see any CSS warnings that come from styles applied during startup (unless the browser console is opened before the first window via a command line flag).

When I look at the browser console, it appears that content CSS warnings comprise orders of magnitude more messages than the chrome CSS warnings. Would the filtering (if it could be done on the content side) make enough of a reduction to remove the perf issue?

[Bobby Holley]

To be clear, there are two motivations of this change:

(1) The performance benefits of not stringifying CSS errors for regular websites

(2) Supporting parallel CSS parsing, where we can't easily do error reporting.

So the idea for content would be that we'd have no CSS errors by default, and toggling them on would disable parallel CSS parsing, enable reporting, and reload.

Given that CSS errors in browser code should be rare, I don't expect (1) to be an issue there. As for (2), I think we can live without parallel parsing for chrome:// sheets.

So as long as we're willing to stop displaying _content_ CSS errors in the browser console, I think we can move forward here.

[Emilio Cobos Álvarez]

On 04/11/2018 09:10 PM, Jared Wein wrote:
> Doing so would make it impossible to see any CSS warnings that come from
> styles applied during startup (unless the browser console is opened
> before the first window via a command line flag).

I'm still wrapping my head about all this setup, but the naive idea for
now to unblock stuff is toggling on the CSS error reporting pref the
first time you switch on the CSS filter, so it would work if you restart
the browser, or launch the browser with the pref set. Would that address
that concern?

That being said, I didn't end up having as much time as I'd have loved
to dig into this today, so the approach could very likely change, since
I'm still not sure about how to pass the relevant state around to Gecko.

It's probably worth to try to figure out a way so that the error
reporting is enabled, let's say, per document, instead of globally, so
that you don't get the perf hit for all the pages at least... But not
sure how easy that may end up being, it may be worth doing it as a followup.

> When I look at the browser console, it appears that content CSS warnings
> comprise orders of magnitude more messages than the chrome CSS warnings.
> Would the filtering (if it could be done on the content side) make
> enough of a reduction to remove the perf issue?

FWIW, the main motivation for this is not just the perf issue, but also
that our error reporting code is written in C++, and while our CSS
parsing code is written in Rust and we're confident on it being
thread-safe, the same cannot be said about that code, like, at all.

We're trying to see how parallel / OMT CSS parsing would look like, and
we wouldn't like to rewrite all this setup for the sake of errors that
are not shown by default. It could be unconditionally enabled for Chrome
documents I guess, I'm not sure if Bobby's patches parse chrome:// URIs
async, I suspect not...

-- Emilio

> On Wed, Apr 11, 2018 at 3:07 PM, Brian Grinstead <bgrin...@mozilla.com
> <mailto:bgrin...@mozilla.com>> wrote:
>
> The content filtering in the Browser Console is pretty close - we
> have one more platform bug in progress to detect messages coming
> from chrome contexts and then a relatively small piece of frontend work.
>
> It sounds like you’d be OK with not ever seeing CSS warnings from
> content pages in the BC, and that you may or may not care about CSS
> warnings from the parent process but don’t know yet until we can
> filter out content messages. Would you care if turning on CSS
> warnings in the parent process didn’t show ‘past’ CSS warnings but
> started showing only new ones?
>
> Brian
>
> > On Apr 11, 2018, at 12:00 PM, Jared Wein <ja...@mozilla.com

> <mailto:ja...@mozilla.com>> wrote:
> >
> > I agree with Dan.
> https://bugzilla.mozilla.org/show_bug.cgi?id=1260877
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1260877> looked close
> to landing a month ago then I think work stalled?
> >
> > - Jared
> >
> > On Wed, Apr 11, 2018 at 2:57 PM, Dan Mosedale
> <dmos...@mozilla.com <mailto:dmos...@mozilla.com>> wrote:
> > Because it's so noisy, presumably in the current form people
> aren't getting a lot of use out of them.  However, I suspect that
> could change substantially if we stopped showing content CSS errors
> in the browser console.  So it seems a bit hard to evaluate the
> usefulness without doing that first.
> >
> > Dan
> >
> > 2018-04-11 11:21 GMT-07:00 Brian Grinstead <bgrin...@mozilla.com

> <mailto:bgrin...@mozilla.com>>:

> > firef...@mozilla.org <mailto:firef...@mozilla.org>
> > https://mail.mozilla.org/listinfo/firefox-dev

> <https://mail.mozilla.org/listinfo/firefox-dev>
> >
> >
> > _______________________________________________
> > firefox-dev mailing list

> > firef...@mozilla.org <mailto:firef...@mozilla.org>
> > https://mail.mozilla.org/listinfo/firefox-dev

[Jared Wein]

On Wed, Apr 11, 2018 at 3:33 PM, Emilio Cobos Álvarez <emi...@mozilla.com> wrote:

On 04/11/2018 09:10 PM, Jared Wein wrote:
> Doing so would make it impossible to see any CSS warnings that come from
> styles applied during startup (unless the browser console is opened
> before the first window via a command line flag).

I'm still wrapping my head about all this setup, but the naive idea for
now to unblock stuff is toggling on the CSS error reporting pref the
first time you switch on the CSS filter, so it would work if you restart
the browser, or launch the browser with the pref set. Would that address
that concern?

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.

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.

- jared

[Brian Grinstead]

> 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

[Matthew N.]

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

[Dão Gottwald]

I'm pretty sure people use this, as we've had bug reports that seemed to stem from console warnings / errors. Personally, I normally don't look at these message because browser console output is too noisy. +1 for getting rid of messages from web content there (with Matt's concern in mind).

dao