Bug 29746
| Summary: | Early returns in FrameLoader::loadURL harmful for plug-ins | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Adam Barth <abarth> |
| Component: | Page Loading | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | ahmad.saleem792, andersca, ap, cmarcelo, fishd, simon.fraser |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | All | ||
| OS: | All | ||
Adam Barth
Comment #6 From Darin Fisher (:fishd, Google) 2009-09-21 00:32:42 PDT (-) [reply]
I think these early returns are problematic for callers of
NPN_Get/PostURLNotify that expect a callback on success _or_ failure. By
suppressing the frame loader notifications, the NPP_URLNotify call will be
suppressed, and that may result in memory leaks in the plugin. (Note: This is
actually only a problem for Chrome since WebKit's plugin implementation has a
bug where it always fires NPP_URLNotify before the load completes.)
I believe the correct solution to this bug is to call
FrameLoaderClient::dispatchDidFailProvisionalLoad somehow instead of just
silently failing the loadURL / loadWithDocumentLoader calls.
Note: It looks like FrameLoader::loadURL has other early returns that could
cause similar problems.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Ahmad Saleem
https://searchfox.org/wubkat/rev/74c0aa4209e14edf714b16d023ac838b718120f8/Source/WebCore/loader/FrameLoader.cpp#1451
Plugins are gone and from above code, do we need to anything further here?
@Simon - I have seen you work on Page Loading bugs in the past (could be my wrong assumption that it might be with you but happy to be corrected and learn something new), should we close this?