[webkit-dev] spamming the developer console

[Adam Barth]

On Fri, May 11, 2012 at 2:29 PM, Ojan Vafai <ojan at chromium.org> wrote:
> 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.

That bug is fixed on trunk.  CSP no longer blocks about:blank for
iframes.  (Blocking about:blank doesn't make any sense because we just
display about:blank when we've blocked an iframe.)

Adam


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