Bug 150776 - Move the ResourceUsageOverlay out of the way by default.
Summary: Move the ResourceUsageOverlay out of the way by default.
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Andreas Kling
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-11-01 11:17 PST by Andreas Kling
Modified: 2015-11-01 14:00 PST (History)
1 user (show)

See Also:


Attachments
Patch (3.98 KB, patch)
2015-11-01 11:18 PST, Andreas Kling
darin: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Kling 2015-11-01 11:17:46 PST
It's annoying that it starts out in the top left corner of the viewport. You have to drag it away every time.
Comment 1 Andreas Kling 2015-11-01 11:18:22 PST
Created attachment 264523 [details]
Patch
Comment 2 Darin Adler 2015-11-01 12:45:03 PST
Comment on attachment 264523 [details]
Patch

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

> Source/WebCore/page/ResourceUsageOverlay.cpp:60
> +    FrameView& frameView = *m_page.mainFrame().view();

What guarantees the view is non-null?
Comment 3 Andreas Kling 2015-11-01 13:45:45 PST
(In reply to comment #2)
> Comment on attachment 264523 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=264523&action=review
> 
> > Source/WebCore/page/ResourceUsageOverlay.cpp:60
> > +    FrameView& frameView = *m_page.mainFrame().view();
> 
> What guarantees the view is non-null?

Through the magic of the initial empty document load, which happens by way of WebKit calling into Frame::init() on the MainFrame during WebPage bringup, we end up constructing a FrameView when transitioning to committed state.

This all happens before the ResourceUsageOverlay is constructed (when the setting is flipped to true, either during WebPage::updatePreferences(), or at any time later through WebCore::Settings API.)

Of course, none of this is remotely obvious from looking at the pointer dereference in context, so I'll just put in a null check. :)
Comment 4 Andreas Kling 2015-11-01 14:00:41 PST
Committed r191861: <http://trac.webkit.org/changeset/191861>