966692 - Reduce the default set of warnings we display in console

Status: VERIFIED FIXED

(DevTools :: Console, defect, P3)

Description

[Anton Kovalyov (:anton)]

When you open NYTimes (for example) on a default profile you easily get overwhelmed with messages. I think we should reduce the default set of messages we display to show only the necessities i.e. stuff that can prevent your page from working correctly.

Comment 1

[Jeff Griffiths (:canuckistani) (:⚡︎)]

+1. I wish that css and JS warnings were more meaningful and less common, but the platform is messy enough that any site using jQuery (which is nearly everyone) vomits warnings into the console.

Strawman for a new default behaviour:

* remove the net category
* all security warnings
* CSS errors only
* JS errors only
* all security messages
* all log levels

Comment 2

[Paul Rouget [:paul]]

> * CSS errors only

Is there such a thing?

Comment 3

[Girish Sharma [:Optimizer]]

(In reply to Paul Rouget [:paul] from comment #2)
> > * CSS errors only
> 
> Is there such a thing?

We have an Error category in CSS filter, but yeah, I have never seen CSS errors. Everything is just warning

Comment 4

[Paul Rouget [:paul]]

See bug 966692.

Comment 5

[Paul Rouget [:paul]]

I meant bug 720343.

Comment 6

[Mihai Sucan [:msucan]]

(In reply to Jeff Griffiths (:canuckistani) from comment #1)
> +1. I wish that css and JS warnings were more meaningful and less common,
> but the platform is messy enough that any site using jQuery (which is nearly
> everyone) vomits warnings into the console.
> 
> Strawman for a new default behaviour:
> 
> * remove the net category
> * all security warnings
> * CSS errors only
> * JS errors only
> * all security messages
> * all log levels

Currently, by default we show:

- all network logs,
- CSS errors only,
- JS errors and warnings,
- all security messages,
- all log levels (console API messages from the page).

The only change that makes sense, in my opinion, is to turn off Network > Log messages, while keeping network errors and warnings visible - I believe these are important enough to be shown by default. With this change I only see 4 messages in the web console when nytimes.com loads. cnn.com is similarly quiet.

We may also turn off JS warnings by default.

Comment 7

[Rob Campbell [:rc] (:robcee)]

+1, I agree and this matches my own settings.

I would also consider disabling Security Warnings.

Comment 8

[Anton Kovalyov (:anton)]

> I would also consider disabling Security Warnings.

I'm not sure if we separate security warnings from security errors. If we don't I think we should. For example, when we don't load fonts because of SOP this should be an error and, IMHO, should appear in the console by default since it breaks the website.

Comment 9

[Rob Campbell [:rc] (:robcee)]

Attachment: prefs

here are some updated prefs

Comment 10

[Mihai Sucan [:msucan]]

Comment on attachment 8374896 [details] [diff] [review]
prefs

Review of attachment 8374896 [details] [diff] [review]:
-----------------------------------------------------------------

r+, with one comment below. I leave the final choice to you.

::: browser/app/profile/firefox.js
@@ +1203,5 @@
>  pref("devtools.webconsole.filter.warn", true);
>  pref("devtools.webconsole.filter.info", true);
>  pref("devtools.webconsole.filter.log", true);
>  pref("devtools.webconsole.filter.secerror", true);
> +pref("devtools.webconsole.filter.secwarn", false);

I would suggest keeping security warnings on. Let's disable them when they become a problem. For now, I believe security is important enough to be visible by default - and we don't have many messages in this category.

Comment 11

[Rob Campbell [:rc] (:robcee)]

Attachment: prefs

Comment 12

[Rob Campbell [:rc] (:robcee)]

updated. Added security warnings back into the file. Ready for landing.

Comment 13

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 8375637 [details] [diff] [review]
prefs

Please stick to just checkin-needed.

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/fx-team/rev/c4aba8973e0f

Comment 15

[Ryan VanderMeulen [:RyanVM]]

Backed out for mochitest-bc failures.
https://hg.mozilla.org/integration/fx-team/rev/5748e84048b3

https://tbpl.mozilla.org/php/getParsedLog.php?id=34636480&tree=Fx-Team

Comment 16

[Rob Campbell [:rc] (:robcee)]

of course there are test failures with this. My bad. fixing...

Comment 17

[Rob Campbell [:rc] (:robcee)]

Attachment: prefs

reverted security.warnings setting and fixed tests.

Comment 18

[Mihai Sucan [:msucan]]

Comment on attachment 8379345 [details] [diff] [review]
prefs

Review of attachment 8379345 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks for the update!

::: browser/devtools/webconsole/test/browser_bug_638949_copy_link_location.js
@@ +17,2 @@
>    registerCleanupFunction(() => {
> +    Services.prefs.setBoolPref("devtools.webconsole.filter.networkinfo", originalNetPref);

You can use clearUserPref() to reset the pref.

Comment 19

[Mihai Sucan [:msucan]]

This is a patch that would be nice in aurora. What do you think?

Comment 20

[Rob Campbell [:rc] (:robcee)]

https://hg.mozilla.org/integration/fx-team/rev/e29ea34afb6c

Comment 21

[Ed Morley [:emorley]]

Backed out for test failures:
https://tbpl.mozilla.org/php/getParsedLog.php?id=35221579&tree=Fx-Team

remote:   https://hg.mozilla.org/integration/fx-team/rev/9e154b693462

Comment 22

[Rob Campbell [:rc] (:robcee)]

failure:

chrome://mochitests/content/browser/browser/devtools/webconsole/test/browser_webconsole_dont_navigate_on_doubleclick.js | Test timed out

Comment 23

[Rob Campbell [:rc] (:robcee)]

third time's the charm!
https://hg.mozilla.org/integration/fx-team/rev/b76d4126d9fe

Comment 24

[Tim Taubert [:ttaubert] (inactive)]

https://hg.mozilla.org/mozilla-central/rev/b76d4126d9fe

Comment 25

[Boris Zbarsky [:bzbarsky]]

I really wish we'd gone with the proposal in comment 6 instead...  I filed 991734 to get sorted out some of the working-at-cross-purposes issues here.  :(

Comment 26

[Andrei Vaida [:avaida]]

This issue is verified fixed on Firefox 30 Beta 3 (Build ID: 20140508121358) [1].

[1] Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0