Bug 113430 - [wk2] REGRESSION (r125500): WebFrameLoaderClient's active m_pluginView can be zeroed by PluginDocuments leaving the page cache
Summary: [wk2] REGRESSION (r125500): WebFrameLoaderClient's active m_pluginView can be...
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: Tim Horton
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2013-03-27 11:43 PDT by Tim Horton
Modified: 2013-05-03 04:46 PDT (History)
5 users (show)

See Also:


Attachments
patch (2.18 KB, patch)
2013-03-27 11:47 PDT, Tim Horton
beidson: review+
Details | Formatted Diff | Diff
patch (1.57 KB, patch)
2013-03-28 14:13 PDT, Tim Horton
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Horton 2013-03-27 11:43:09 PDT
http://trac.webkit.org/changeset/125500 made a change that purported to be Chromium only (it even had a [chromium] tag!) but actually changed the behavior for WebKit2 as well:

It now zeroes the FrameLoaderClient's redirecting-PluginView in PluginDocument::detach(), which can happen *way later* in the case that the PluginDocument went into the page cache, clearing a legitimate-and-different PluginView from (Web)FrameLoaderClient.

This change also made sure not to change behavior for other ports, ignoring the new redirectDataToPlugin(0) case, but missed WebKit2 (possibly intentionally because m_pluginView is a RefPtr for WK2 and not for most other non-Chromium ports). We already clear the m_pluginView RefPtr when the load finishes or fails, so I think we can safely early-return in the redirectDataToPlugin(0) case just like all the other ports, returning to our behavior before r125500.

<rdar://problem/12729564>
Comment 1 Tim Horton 2013-03-27 11:47:53 PDT
Created attachment 195369 [details]
patch
Comment 2 Brady Eidson 2013-03-28 12:02:19 PDT
Comment on attachment 195369 [details]
patch

Sloppy patch originally  :(  Fix seems reasonable.
Comment 3 Tim Horton 2013-03-28 13:22:54 PDT
http://trac.webkit.org/changeset/147152
Comment 4 Darin Adler 2013-03-28 14:02:24 PDT
Comment on attachment 195369 [details]
patch

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

> Source/WebKit2/WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp:1350
> -    m_pluginView = static_cast<PluginView*>(pluginWidget);
> +    if (m_pluginView)
> +        m_pluginView = static_cast<PluginView*>(pluginWidget);

I think you mean:

    if (pluginWidget)

not

    if (m_pluginView)
Comment 5 Tim Horton 2013-03-28 14:04:06 PDT
(In reply to comment #4)
> (From update of attachment 195369 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=195369&action=review
> 
> > Source/WebKit2/WebProcess/WebCoreSupport/WebFrameLoaderClient.cpp:1350
> > -    m_pluginView = static_cast<PluginView*>(pluginWidget);
> > +    if (m_pluginView)
> > +        m_pluginView = static_cast<PluginView*>(pluginWidget);
> 
> I think you mean:
> 
>     if (pluginWidget)
> 
> not
> 
>     if (m_pluginView)

Woah, you're right. How I manage to screw up one line patches I'll never know.
Comment 6 Brady Eidson 2013-03-28 14:08:44 PDT
And me too  :(
Comment 7 Tim Horton 2013-03-28 14:12:30 PDT
Reopening for correct fix.
Comment 8 Tim Horton 2013-03-28 14:13:24 PDT
Created attachment 195638 [details]
patch
Comment 9 Tim Horton 2013-03-28 15:06:27 PDT
(In reply to comment #8)
> Created an attachment (id=195638) [details]
> patch

http://trac.webkit.org/changeset/147168