[webkit-dev] spamming the developer console

[Ojan Vafai]

On Fri, May 11, 2012 at 2:25 PM, Adam Barth <abarth at webkit.org> wrote:

> On Fri, 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
>
> ^^^ Why isn't this a bug that developers would want to fix?
>

For example, in some code I just wrote, I append an iframe to the DOM, then
at some later point set its src. When I append the iframe to the DOM, it
tries to load about:blank, which CSP disallows. I could restructure the
code to not append the iframe until I know what it's source will be, but it
makes the code more complicated than it needs to be. The only downside to
appending it first is this warning.


>
> > -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.
> >
> > Ojan
> >
> > _______________________________________________
> > webkit-dev mailing list
> > webkit-dev at lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120511/09901ce9/attachment.html>