WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED DUPLICATE of
bug 98492
Bug 107704
Web Inspector: MIME type errors should be "debug" level.
https://bugs.webkit.org/show_bug.cgi?id=107704
Summary
Web Inspector: MIME type errors should be "debug" level.
Mike West
Reported
2013-01-23 10:38:52 PST
Moving the "Resource interpreted as XXX but transferred as MIME type XXX" message to debug level (down from warning) seems appropriate. It's much more of a debug message than a warning (though those boundaries are blurry).
Attachments
Patch
(1.81 KB, patch)
2013-01-23 10:41 PST
,
Mike West
pfeldman
: review-
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Mike West
Comment 1
2013-01-23 10:41:38 PST
Created
attachment 184261
[details]
Patch
Pavel Feldman
Comment 2
2013-01-24 05:25:04 PST
Comment on
attachment 184261
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=184261&action=review
> Source/WebCore/inspector/front-end/NetworkManager.js:185 > + WebInspector.ConsoleMessage.MessageLevel.Debug,
I think that this is still a warning. It should be filtered out by source, not severity. Like I know how console.warn, console.error and console.log are processed. I can stick to some standard in my code and tune my filters accordingly. But I don't know what severity is set for the internal messages. My guess would be that they match the common sense: - warnings warn about errors browser could recover from - errors report problems browser could not recover from - debug generates verbose debugging info flow - I would not expect browser to generate Log level messages to me. I think there should be a set of checkboxes ("Network", "CSS", "JavaScript") in console that would filter by source (in addition to existing message level).
Mike West
Comment 3
2013-01-24 05:34:17 PST
(In reply to
comment #2
)
> > Source/WebCore/inspector/front-end/NetworkManager.js:185 > > + WebInspector.ConsoleMessage.MessageLevel.Debug, > > I think that this is still a warning. It should be filtered out by source, not severity. > ... > - warnings warn about errors browser could recover from > - errors report problems browser could not recover from
This makes perfect sense to me.
> - debug generates verbose debugging info flow
What constitutes "debug" information? Right now, the only message using it is `console.timeEnd`. Not even `console.debug()` outputs at the Debug level (which makes very little sense to me).
> - I would not expect browser to generate Log level messages to me.
Currently, almost nothing generates Log-level messages: `console.{debug,log,dir,dirxml,clear,trace,startgroup,endgroup,profile,count}` all output at log level, but the only "internal" message at Log level is "XHR finished loading: %s" that users can opt into.
> I think there should be a set of checkboxes ("Network", "CSS", "JavaScript") in console that would filter by source (in addition to existing message level).
I do think this makes sense, though I'm not at all sure how to present them. :) If that's the right solution, I'd suggest duping this bug against
https://bugs.webkit.org/show_bug.cgi?id=98492
and working through UI there.
Pavel Feldman
Comment 4
2013-01-24 05:58:19 PST
> > - debug generates verbose debugging info flow > > What constitutes "debug" information? Right now, the only message using it is `console.timeEnd`. Not even `console.debug()` outputs at the Debug level (which makes very little sense to me).
I think we should fix console.debug to use proper level.
> > - I would not expect browser to generate Log level messages to me. > > Currently, almost nothing generates Log-level messages: `console.{debug,log,dir,dirxml,clear,trace,startgroup,endgroup,profile,count}` all output at log level, but the only "internal" message at Log level is "XHR finished loading: %s" that users can opt into.
I am not sure about this one. It looks like a debug level to me. We could tell user to set Network message's level to debug to see that.
> > > I think there should be a set of checkboxes ("Network", "CSS", "JavaScript") in console that would filter by source (in addition to existing message level). > > I do think this makes sense, though I'm not at all sure how to present them. :) If that's the right solution, I'd suggest duping this bug against
https://bugs.webkit.org/show_bug.cgi?id=98492
and working through UI there.
Merging sounds good. I was thinking of a "Sound Mixer" view where there were vertical severity bars (one per message source).
Mike West
Comment 5
2013-01-24 06:10:38 PST
(In reply to
comment #4
)
> I think we should fix console.debug to use proper level.
I'll throw a patch up at
https://bugs.webkit.org/show_bug.cgi?id=107816
in a moment. An open question I've asked there: what about `console.info`? Is that TipMessageLevel? Should we have `console.tip`? Should we kill TipMessageLevel entirely, since I have no idea what it means and we're only using it once? :)
> > > - I would not expect browser to generate Log level messages to me. > > > > Currently, almost nothing generates Log-level messages: `console.{debug,log,dir,dirxml,clear,trace,startgroup,endgroup,profile,count}` all output at log level, but the only "internal" message at Log level is "XHR finished loading: %s" that users can opt into. > > I am not sure about this one. It looks like a debug level to me. We could tell user to set Network message's level to debug to see that.
Yeah, I think it's debug level as well:
https://bugs.webkit.org/show_bug.cgi?id=107817
> > I do think this makes sense, though I'm not at all sure how to present them. :) If that's the right solution, I'd suggest duping this bug against
https://bugs.webkit.org/show_bug.cgi?id=98492
and working through UI there. > > Merging sounds good. I was thinking of a "Sound Mixer" view where there were vertical severity bars (one per message source).
Hrm. That sounds complicated, but we can try it out. I'll merge this bug in and we can fiddle with a solution over there. *** This bug has been marked as a duplicate of
bug 98492
***
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug