I broadly concur, and option (1) feels sensible. Here's my variant of option (1) and (4): display all these warnings by default but allow the user to click on one and select something like "suppress all", which will suppress all warnings of that kind in the current session. Also have a reset which will unsuppress all suppressed warnings. This would require is having IDs for different kinds of warnings. I don't know if we have plumbing for that but it seems easy to add.
The reasoning behind this is that many if these warnings may be useful and informative at first glance - in the sense that they educate the programmer about what's going on - but then they become useless noise when the programmer is trying to find other issues. -Filip On May 11, 2012, at 2:21 PM, Ojan Vafai <[email protected]> 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. > > Ojan > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
