Click-to-load for blocked plugins is going to use this pseudo-plugin.
Created attachment 59379 [details] Adds WebDOMUIPlugin, WebDOMUIPluginClient and WebDOMUIPluginImpl.
Comment on attachment 59379 [details] Adds WebDOMUIPlugin, WebDOMUIPluginClient and WebDOMUIPluginImpl. I think this code (minus the changes to existing WebKit API interfaces) belongs in the chromium repository. The concept of DOM UI is a chromium thing. Am I missing a reason why this is best to have as part of the WebKit API?
(In reply to comment #2) > (From update of attachment 59379 [details]) > I think this code (minus the changes to existing WebKit API interfaces) belongs > in the chromium repository. The concept of DOM UI is a chromium thing. > > Am I missing a reason why this is best to have as part of the WebKit API? The drawing code (getting a GraphicsContext from a WebCanvas and doing the necessary transformations on it) depends on WebKit code that's not publicly exposed. I tried keeping the changes to the public interface as small as possible though. I'm not really happy about the name WebDOMUIPlugin either, do you think something like WebViewPlugin would be better?
(In reply to comment #3) > The drawing code (getting a GraphicsContext from a WebCanvas and doing the > necessary transformations on it) depends on WebKit code that's not publicly > exposed. I tried keeping the changes to the public interface as small as > possible though. I see. I would imagine that it is possible to do the equivalent transforms using Skia/CG directly. > I'm not really happy about the name WebDOMUIPlugin either, do you think something like WebViewPlugin would be better? Yeah, WebViewPlugin would probably be better.
LayoutTest failures for Chromium are being marked WontFix. The Bug is still accessible and referenced from TestExpectations.