On Fri, May 11, 2012 at 2:25 PM, Adam Barth <aba...@webkit.org> wrote:
> On Fri, May 11, 2012 at 2:21 PM, Ojan Vafai <o...@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@lists.webkit.org > > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
