Summary: | Move the ResourceUsageOverlay out of the way by default. | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Andreas Kling <kling> | ||||
Component: | WebCore Misc. | Assignee: | Andreas Kling <kling> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | kling | ||||
Priority: | P2 | ||||||
Version: | WebKit Nightly Build | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Attachments: |
|
Description
Andreas Kling
2015-11-01 11:17:46 PST
Created attachment 264523 [details]
Patch
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? (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. :) Committed r191861: <http://trac.webkit.org/changeset/191861> |