[webkit-dev] spamming the developer console

[Maciej Stachowiak]

On May 11, 2012, at 2:21 PM, Ojan Vafai <ojan at chromium.org> wrote:

> The amount of spam we throw in the developer console has grown quite a bit.
> 
> spam == things logged to the console that web developers have no control over
> 
> Unlike uncaught javascript exceptions (which can easily just be caught), there is no way to prevent the following from cluttering your console:
> -clientX/clientY deprecation warning
> -setting the fragment on a frame URL [1]
> -loading a resource disallowed by CSP
> -attempting to load a resource (e.g. in an image or iframe) that doesn't exist
> 
> These warnings are not developer friendly. The equivalent would be to have compiler warnings that you are unable to turn off. It clutters the console and makes many console use-cases harder (e.g. console.log style debugging). We need a better solution.
> 
> In many cases, these warnings don't actually represent bugs in the program (e.g. the are legit reasons to try to load a non-existent resource in an image element).
> 
> Some potential solutions:
> 1. Create a new loggling level (browserwarnings?) in addition to the current errors/warnings/logs. This kind of half-solves the problem since you can't just side these logs.
> 2. Have preventDefault in an onError handler prevent logging these to the console (works for the navigation warnings).
> 3. Have some other inspector panel where these get logged.
> 4. Have some window-level state that disables all these sorts of warnings (or something more fine-grained like being able to disable deprecation warnings and navigation warnings separately).
> 5. ???
> 
> My preference would be to do both options 1 and 2 (they're not mutually exclusive), unless someone has a better suggestion.

It seems like items related to networking (which is most of the above, other than deprecation warnings) could be represented in resource-oriented views instead of in the console. That way you can still see if something failed to load, but at the time of looking at loading rather than looking for JS-related information and errors.

As for deprecation warnings, I am not a huge fan of them, but if there is an easy way to turn them off or ignore them, then they are even less likely to have any benefit.

For clientX/clientY specifically, I don't know why we would want to deprecate it in the first place, and I don't recall a discussion here about deprecating them. Is there a good reason to eventually get rid of clientX/clientY? If not, let's just get rid of the warning on that one.

Regards,
Maciej