Bug 140323 - Log navigation types using DiagnosticLoggingClient
Summary: Log navigation types using DiagnosticLoggingClient
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Page Loading (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Chris Dumez
URL:
Keywords: InRadar
Depends on:
Blocks: 140463
  Show dependency treegraph
 
Reported: 2015-01-09 16:06 PST by Chris Dumez
Modified: 2015-01-14 13:39 PST (History)
6 users (show)

See Also:


Attachments
Patch (5.66 KB, patch)
2015-01-09 16:10 PST, Chris Dumez
no flags Details | Formatted Diff | Diff
Patch (5.58 KB, patch)
2015-01-12 12:26 PST, Chris Dumez
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Dumez 2015-01-09 16:06:38 PST
Log navigation types using DiagnosticLoggingClient to help us understand what types of navigations are common and give us an estimate on the total number of navigations.

Radar: <rdar://problem/19432920>
Comment 1 Chris Dumez 2015-01-09 16:10:51 PST
Created attachment 244385 [details]
Patch
Comment 2 Darin Adler 2015-01-12 10:52:11 PST
Comment on attachment 244385 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=244385&action=review

> Source/WebCore/loader/FrameLoader.cpp:1422
> +    if (page->settings().diagnosticLoggingEnabled()) {

If settings() were hanging off the main frame, then we would not need to involve the page at all. It would be way nicer if this was a main frame thing and not a page thing.

> Source/WebCore/loader/FrameLoader.cpp:1424
> +        if (DiagnosticLoggingClient* diagnosticLoggingClient = page->mainFrame().diagnosticLoggingClient())
> +            diagnosticLoggingClient->logDiagnosticMessage(DiagnosticLoggingKeys::navigationKey(), navigationDescription);

I’d name this local variable “client”, not “diagnosticLoggingClient” since its scope is just this tiny if statement.

I’d use auto* to avoid repeating the long type name.

It seems a shame that logDiagnosticMessage takes a String. If these are all string literals then why doesn’t it just take a const char*?
Comment 3 Darin Adler 2015-01-12 10:52:44 PST
Comment on attachment 244385 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=244385&action=review

> Source/WebCore/page/DiagnosticLoggingKeys.h:46
> +    static String navigationKey();

I think these should all be const char*. No reason to reference count all these string literals.
Comment 4 Anders Carlsson 2015-01-12 10:54:02 PST
(In reply to comment #2)
> Comment on attachment 244385 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=244385&action=review
> 
> > Source/WebCore/loader/FrameLoader.cpp:1422
> > +    if (page->settings().diagnosticLoggingEnabled()) {
> 
> If settings() were hanging off the main frame, then we would not need to
> involve the page at all. It would be way nicer if this was a main frame
> thing and not a page thing.
> 

Settings are ref-counted now, and each frame has a Settings object:

        Settings& settings() const { return *m_settings; }
Comment 5 Chris Dumez 2015-01-12 12:23:38 PST
Comment on attachment 244385 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=244385&action=review

>>> Source/WebCore/loader/FrameLoader.cpp:1422
>>> +    if (page->settings().diagnosticLoggingEnabled()) {
>> 
>> If settings() were hanging off the main frame, then we would not need to involve the page at all. It would be way nicer if this was a main frame thing and not a page thing.
> 
> Settings are ref-counted now, and each frame has a Settings object:
> 
>         Settings& settings() const { return *m_settings; }

Ok, I will get the settings from the MainFrame instead.

>> Source/WebCore/loader/FrameLoader.cpp:1424
>> +            diagnosticLoggingClient->logDiagnosticMessage(DiagnosticLoggingKeys::navigationKey(), navigationDescription);
> 
> I’d name this local variable “client”, not “diagnosticLoggingClient” since its scope is just this tiny if statement.
> 
> I’d use auto* to avoid repeating the long type name.
> 
> It seems a shame that logDiagnosticMessage takes a String. If these are all string literals then why doesn’t it just take a const char*?

Yes, I think those can be const char*. Do you mind mind if I do this in a separate patch? There is quite a bit of existing code to update.
Comment 6 Chris Dumez 2015-01-12 12:26:39 PST
Created attachment 244455 [details]
Patch
Comment 7 WebKit Commit Bot 2015-01-12 14:31:04 PST
Comment on attachment 244455 [details]
Patch

Clearing flags on attachment: 244455

Committed r178298: <http://trac.webkit.org/changeset/178298>
Comment 8 WebKit Commit Bot 2015-01-12 14:31:08 PST
All reviewed patches have been landed.  Closing bug.
Comment 9 Chris Dumez 2015-01-12 14:45:28 PST
(In reply to comment #3)
> Comment on attachment 244385 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=244385&action=review
> 
> > Source/WebCore/page/DiagnosticLoggingKeys.h:46
> > +    static String navigationKey();
> 
> I think these should all be const char*. No reason to reference count all
> these string literals.

In several cases, logDiagnosticMessage() is called with non-literals (http status codes constructed using String::number(), MIME types, ...). So the logDiagnosticMessage*() take Strings in arguments.