[webkit-dev] spamming the developer console

[Ojan Vafai]

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

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

Ugh. I was a little wrong here. The 404 errors do show you a stacktrace.
Still, it seems like we should find a way to fit that into the network
panel. While we're at it, it would be nice for the CSP and fragment on
frame cases to show you a stacktrace as well.

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/9e5db989/attachment.html>