Bugs filed. Navigation warnings: https://bugs.webkit.org/show_bug.cgi?id=86263. clientX/clientY: https://bugs.webkit.org/show_bug.cgi?id=86264. Would be good for someone informed on that issue to chime in.
On Fri, May 11, 2012 at 3:08 PM, Ojan Vafai <[email protected]> wrote: > 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
