WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
Bug 99941
Web Inspector: Pipe requests through to Inspector in order to add "initiator" links to messages.
https://bugs.webkit.org/show_bug.cgi?id=99941
Summary
Web Inspector: Pipe requests through to Inspector in order to add "initiator"...
Mike West
Reported
2012-10-21 11:17:16 PDT
Messages associated with requests can generally be improved by linking to the point at which the message was generated. I had a quick conversation with Pavel about this, he suggested to file a bug to continue the discussion. As an example, the mixed content warning "The page at XXX displayed insecure content from YYY." should link off to the element or code snippet that caused the insecure resource to load (see
https://mkw.st/p/mixed/
for an example of the current state). This will be partially resolved with 97979, which adds a call stack when relevant, but won't help when the resource is loaded by the parser. If no call stack is present, it would make sense to use that space to link to the request's initiator. I've dug around a bit to see how this might work. The only place I've found that creates a console message with a requestID set is the mixed MIME type error from inside the inspector (NetworkManager.js:191). Is there a mechanism to bind requests and console messages together when creating the message from WebCore? If not, I think the best I can do is to do a 'resourceForURL' lookup for every URL I see in the message, which seems error-prone. WDYT?
Attachments
Adding a new 'addMessageToConsole' method.
(13.06 KB, patch)
2012-10-26 07:19 PDT
,
Mike West
no flags
Details
Formatted Diff
Diff
How usage might look.
(9.99 KB, patch)
2012-10-26 07:20 PDT
,
Mike West
no flags
Details
Formatted Diff
Diff
Patch
(36.29 KB, patch)
2012-10-29 04:40 PDT
,
Mike West
no flags
Details
Formatted Diff
Diff
Patch
(39.93 KB, patch)
2012-10-29 05:40 PDT
,
Mike West
no flags
Details
Formatted Diff
Diff
Patch
(39.95 KB, patch)
2012-10-30 05:20 PDT
,
Mike West
no flags
Details
Formatted Diff
Diff
Patch for landing
(39.95 KB, patch)
2012-10-30 05:22 PDT
,
Mike West
no flags
Details
Formatted Diff
Diff
Show Obsolete
(5)
View All
Add attachment
proposed patch, testcase, etc.
Pavel Feldman
Comment 1
2012-10-23 09:26:16 PDT
See ConsoleMessage.cpp:148, it does: jsonObj->setNetworkRequestId(m_requestId)
Mike West
Comment 2
2012-10-26 05:44:20 PDT
(In reply to
comment #1
)
> See ConsoleMessage.cpp:148, it does: > > jsonObj->setNetworkRequestId(m_requestId)
Got it, thanks! At the moment, the only mechanisms to pass a request identifier into the inspector seems to be ' InspectorConsoleAgent::didFinishXHRLoading', 'InspectorConsoleAgent::didReceiveResponse', and 'InspectorConsoleAgent::didFailLoading'. I'd like to expose a new variant of 'addMessageToConsole' to allow passing a request identifier in from various other points in WebCore. I'll spin up a strawman patch for discussion soonish.
Mike West
Comment 3
2012-10-26 07:19:05 PDT
Created
attachment 170919
[details]
Adding a new 'addMessageToConsole' method.
Mike West
Comment 4
2012-10-26 07:19:28 PDT
Comment on
attachment 170919
[details]
Adding a new 'addMessageToConsole' method. Not for landing, but a strawman of how this might look.
Mike West
Comment 5
2012-10-26 07:20:08 PDT
Created
attachment 170920
[details]
How usage might look. Again, not for landing, but an example of how the new addToConsole method might be useful.
Pavel Feldman
Comment 6
2012-10-29 01:31:00 PDT
Comment on
attachment 170919
[details]
Adding a new 'addMessageToConsole' method. View in context:
https://bugs.webkit.org/attachment.cgi?id=170919&action=review
> Source/WebCore/page/Console.h:58 > + void addMessage(MessageSource, MessageType, MessageLevel, const String& message, const String& sourceURL = String(), unsigned lineNumber = 0, PassRefPtr<ScriptCallStack> = 0, unsigned long identifier = 0);
requestIdentifier?
> Source/WebCore/page/Console.h:60 > + void addMessage(MessageSource, MessageType, MessageLevel, const String& message, unsigned long identifier, const String& url);
Why do we need this one? Is this convenience method? It sounds like its arguments fall into a subset of the one you are adjusting above.
Mike West
Comment 7
2012-10-29 01:33:15 PDT
(In reply to
comment #6
)
> (From update of
attachment 170919
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=170919&action=review
> > > Source/WebCore/page/Console.h:58 > > + void addMessage(MessageSource, MessageType, MessageLevel, const String& message, const String& sourceURL = String(), unsigned lineNumber = 0, PassRefPtr<ScriptCallStack> = 0, unsigned long identifier = 0); > > requestIdentifier?
Yup. That's a better name.
> > > Source/WebCore/page/Console.h:60 > > + void addMessage(MessageSource, MessageType, MessageLevel, const String& message, unsigned long identifier, const String& url); > > Why do we need this one? Is this convenience method? It sounds like its arguments fall into a subset of the one you are adjusting above.
Just convenience. It seemed reasonable to have a separate method for resource-related console messages for the same reasons it's nice to have a separate method for url/line-number and stacktrace messages.
Pavel Feldman
Comment 8
2012-10-29 01:35:21 PDT
Comment on
attachment 170919
[details]
Adding a new 'addMessageToConsole' method. View in context:
https://bugs.webkit.org/attachment.cgi?id=170919&action=review
>>> Source/WebCore/page/Console.h:60 >>> + void addMessage(MessageSource, MessageType, MessageLevel, const String& message, unsigned long identifier, const String& url); >> >> Why do we need this one? Is this convenience method? It sounds like its arguments fall into a subset of the one you are adjusting above. > > Just convenience. It seemed reasonable to have a separate method for resource-related console messages for the same reasons it's nice to have a separate method for url/line-number and stacktrace messages.
You don't need another Instrumentation method then - we only want such convenience for the call sites, not inside the inspector guts.
Mike West
Comment 9
2012-10-29 01:39:05 PDT
(In reply to
comment #8
)
> (From update of
attachment 170919
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=170919&action=review
> > >>> Source/WebCore/page/Console.h:60 > >>> + void addMessage(MessageSource, MessageType, MessageLevel, const String& message, unsigned long identifier, const String& url); > >> > >> Why do we need this one? Is this convenience method? It sounds like its arguments fall into a subset of the one you are adjusting above. > > > > Just convenience. It seemed reasonable to have a separate method for resource-related console messages for the same reasons it's nice to have a separate method for url/line-number and stacktrace messages. > > You don't need another Instrumentation method then - we only want such convenience for the call sites, not inside the inspector guts.
You're right; this would be covered by the new method on Document. I'll spin a new patch.
Mike West
Comment 10
2012-10-29 02:36:50 PDT
(In reply to
comment #9
)
> (In reply to
comment #8
) > > (From update of
attachment 170919
[details]
[details]) > > View in context:
https://bugs.webkit.org/attachment.cgi?id=170919&action=review
> > > > >>> Source/WebCore/page/Console.h:60 > > >>> + void addMessage(MessageSource, MessageType, MessageLevel, const String& message, unsigned long identifier, const String& url); > > >> > > >> Why do we need this one? Is this convenience method? It sounds like its arguments fall into a subset of the one you are adjusting above. > > > > > > Just convenience. It seemed reasonable to have a separate method for resource-related console messages for the same reasons it's nice to have a separate method for url/line-number and stacktrace messages. > > > > You don't need another Instrumentation method then - we only want such convenience for the call sites, not inside the inspector guts. > > You're right; this would be covered by the new method on Document. I'll spin a new patch.
Actually, now that I look at the Instrumentation code again, I'm not sure I understand your suggestion. Currently, we have two InspectorInstrumentation::addMessageToConsole methods: one for line numbered messages, and one for stack traces (well, four, since those two are replicated for workers). This patch adds another for request identifiers. Are you suggesting that those should be combined into one method that accepts all relevant arguments, and decides which ConsoleMessage to construct based upon the given parameters?
Mike West
Comment 11
2012-10-29 04:40:37 PDT
Created
attachment 171204
[details]
Patch
Mike West
Comment 12
2012-10-29 04:42:53 PDT
After a bit of discussion with Pavel (thanks!), I've cleaned up this patch, and updated 'InspectorConsoleAgent::didFinishXHRLoading', 'InspectorConsoleAgent::didReceiveResponse', and 'InspectorConsoleAgent::didFailLoading' to use the new parameter on 'addMessageToConsole' rather than replicating the work themselves. That should test that the existing functionality works as expected. I'll repurpose 97979 to use this functionality once it lands, which will still more or less look like
https://bugs.webkit.org/attachment.cgi?id=170920
. WDYT?
Pavel Feldman
Comment 13
2012-10-29 04:48:37 PDT
Comment on
attachment 171204
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=171204&action=review
> Source/WebCore/dom/ScriptExecutionContext.h:86 > + void addConsoleMessage(MessageSource, MessageType, MessageLevel, const String& message, const String& sourceURL = String(), unsigned lineNumber = 0, PassRefPtr<ScriptCallStack> = 0, unsigned long requestIdentifier = 0);
Are there any immediate clients for this one?
> Source/WebCore/inspector/InspectorConsoleAgent.cpp:159 > + String requestId = requestIdentifier ? IdentifiersFactory::requestId(requestIdentifier) : String();
You could push this further and make ConsoleMessage constructor accept unsigned long. You would be able to leave more code below as is then.
Mike West
Comment 14
2012-10-29 05:04:35 PDT
(In reply to
comment #13
)
> (From update of
attachment 171204
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=171204&action=review
> > > Source/WebCore/dom/ScriptExecutionContext.h:86 > > + void addConsoleMessage(MessageSource, MessageType, MessageLevel, const String& message, const String& sourceURL = String(), unsigned lineNumber = 0, PassRefPtr<ScriptCallStack> = 0, unsigned long requestIdentifier = 0); > > Are there any immediate clients for this one?
No. I'll need to do some work in the callers to pipe a request identifier in. I'm happy to drop it from the patch and add it in with a client if that's something you'd like to see.
> > > Source/WebCore/inspector/InspectorConsoleAgent.cpp:159 > > + String requestId = requestIdentifier ? IdentifiersFactory::requestId(requestIdentifier) : String(); > > You could push this further and make ConsoleMessage constructor accept unsigned long. You would be able to leave more code below as is then.
That makes sense. I'll make this change.
Mike West
Comment 15
2012-10-29 05:40:38 PDT
Created
attachment 171210
[details]
Patch
Mike West
Comment 16
2012-10-29 05:42:54 PDT
(In reply to
comment #14
)
> > > Source/WebCore/inspector/InspectorConsoleAgent.cpp:159 > > > + String requestId = requestIdentifier ? IdentifiersFactory::requestId(requestIdentifier) : String(); > > > > You could push this further and make ConsoleMessage constructor accept unsigned long. You would be able to leave more code below as is then. > > That makes sense. I'll make this change.
I've made half of this change. :) I pushed the IdentifiersFactory::requestId call down into ConsoleMessage (and adjusted it to return an empty string if provided with 0 as an ID to obviate the 'if' here). I haven't, however, reverted the changes to call addMessageToConsole. It makes more sense to me to centralize the logic about which ConsoleMessage to create in that method, rather than spreading it out over these three. These methods generate a message, but I think they should hand off to the existing method to push it to the console. WDYT?
Mike West
Comment 17
2012-10-30 03:07:16 PDT
(In reply to
comment #14
)
> (In reply to
comment #13
) > > (From update of
attachment 171204
[details]
[details]) > > View in context:
https://bugs.webkit.org/attachment.cgi?id=171204&action=review
> > > > > Source/WebCore/dom/ScriptExecutionContext.h:86 > > > + void addConsoleMessage(MessageSource, MessageType, MessageLevel, const String& message, const String& sourceURL = String(), unsigned lineNumber = 0, PassRefPtr<ScriptCallStack> = 0, unsigned long requestIdentifier = 0); > > > > Are there any immediate clients for this one? > > No. I'll need to do some work in the callers to pipe a request identifier in. I'm happy to drop it from the patch and add it in with a client if that's something you'd like to see.
There's now a client of this change in 100735. Would you like me to move the ScriptExecutionContext/Document changes into that patch, or are you ok with landing this patch as-is?
Pavel Feldman
Comment 18
2012-10-30 04:41:09 PDT
Comment on
attachment 171210
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=171210&action=review
> Source/WebCore/inspector/InspectorConsoleAgent.cpp:159 > + String requestId = requestIdentifier ? IdentifiersFactory::requestId(requestIdentifier) : String();
You don't need it anymore?
> Source/WebCore/inspector/InspectorConsoleAgent.cpp:167 > + String requestId = requestIdentifier ? IdentifiersFactory::requestId(requestIdentifier) : String();
ditto
Mike West
Comment 19
2012-10-30 05:20:58 PDT
Created
attachment 171423
[details]
Patch
Mike West
Comment 20
2012-10-30 05:22:16 PDT
Created
attachment 171424
[details]
Patch for landing
WebKit Review Bot
Comment 21
2012-10-30 09:56:29 PDT
Comment on
attachment 171424
[details]
Patch for landing Clearing flags on attachment: 171424 Committed
r132918
: <
http://trac.webkit.org/changeset/132918
>
WebKit Review Bot
Comment 22
2012-10-30 09:56:34 PDT
All reviewed patches have been landed. Closing bug.
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