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