Bug 93363 - Blocking a plugin with an invalid type via CSP calls SubframeLoader::requestPlugin at page destruction.
Summary: Blocking a plugin with an invalid type via CSP calls SubframeLoader::requestP...
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: Plug-ins (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Brent Fulgham
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-07 06:20 PDT by Mike West
Modified: 2016-04-12 14:59 PDT (History)
4 users (show)

See Also:


Attachments
Passing test which makes the next test fail. (1.38 KB, patch)
2012-08-07 06:21 PDT, Mike West
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mike West 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.
Comment 1 Mike West 2012-08-07 06:21:04 PDT
Created attachment 156928 [details]
Passing test which makes the next test fail.
Comment 2 Brent Fulgham 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.