[webkit-dev] spamming the developer console

[Ojan Vafai]

Bugs filed.

Navigation warnings: https://bugs.webkit.org/show_bug.cgi?id=86263.
clientX/clientY: https://bugs.webkit.org/show_bug.cgi?id=86264. Would be
good for someone informed on that issue to chime in.

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

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