Bug 93363

Summary: Blocking a plugin with an invalid type via CSP calls SubframeLoader::requestPlugin at page destruction.
Product: WebKit Reporter: Mike West <mkwst>
Component: Plug-insAssignee: Brent Fulgham <bfulgham>
Status: RESOLVED INVALID    
Severity: Normal CC: abarth, bauerb, bfulgham, dbates
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Passing test which makes the next test fail. none

Mike West
Reported 2012-08-07 06:20:23 PDT
The attached test case passes, but then makes whatever test run next fail (on the Chromium linux port: we didn't try it on Mac). I walked through this for about an hour and a half with Bernhard, and I'm just confused. The RenderEmbeddedObject renderer is thrown away upon navigation, which makes sense. What doesn't make sense is that it doesn't seem to be the same RenderEmbeddedObject that we mark as unavailable when initially trying to load the plugin. A workaround is to teach the plugin element about it's blocked reason, moving that test from the renderer, which we apparently can't trust, out to the element, which we can.
Attachments
Passing test which makes the next test fail. (1.38 KB, patch)
2012-08-07 06:21 PDT, Mike West 		no flags
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Mike West
Comment 1 2012-08-07 06:21:04 PDT
Created attachment 156928 [details] Passing test which makes the next test fail.
Brent Fulgham
Comment 2 2016-04-12 14:59:23 PDT
This test does not fail, nor does it cause any other tests to fail after it has run. Perhaps Ander's revamping of the plugin system corrected the problem, or other changes in the loader have resolved the issue.
Note You need to log in before you can comment on or make changes to this bug.