[webkit-dev] spamming the developer console

[Ojan Vafai]

On Fri, May 11, 2012 at 2:39 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> 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.
>

Just addressing the networking items is enough to satisfy me. The
deprecation warnings are a much more complicated discussion and IMO less
severe of an annoyance. Or, I suppose, the point of them is to be annoying.

Showing these errors in the network panel instead of in the console sounds
good to me, especially since we don't associate a
line-number/stacktrace/file with them anyways. The only downside here is
that you need to have the inspector open when the load occurs in order to
get the error, but that seems fine with me.

In fact, the non-existant resource warning is already redundant with
information in the network panel. So, really we should just kill those and
find a home for CSP and fragment on frame cases.

Speaking of the fragment on frame cases, why do we ever disallow setting
the fragment on a frame? That seems unnecessarily restrictive to me. I
thought the security issue was addressed by just avoiding scrolling when
the fragment is set.

Ojan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120511/5c0f6803/attachment.html>