On Fri, May 11, 2012 at 2:48 PM, Ojan Vafai <[email protected]> wrote:
> On Fri, May 11, 2012 at 2:39 PM, Maciej Stachowiak <[email protected]> wrote: > >> >> 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. >> >> 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 >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
