[Webkit-unassigned] [Bug 67584] [Chromium] Add WebSandboxSupport and WebThemeEngine for Android.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=67584





--- Comment #14 from Peter Beverloo <peter at chromium.org>  2011-09-06 04:23:41 PST ---
(In reply to comment #13)
> > 
> > > Source/WebKit/chromium/public/android/WebSandboxSupport.h:36
> > > +// FIXME: Empty class for now, as we need it to compile.
> > 
> > Please link to a bug so this ugliness doesn't get forgotten about.
> > 
> 
> Actually, I don't think it's ugly at all. All we need is a null class to conform to the APIs. And we don't have any methods in our own code (not yet upstreamed code) also, until now at least. It's same as extracting an interface, and providing some substantial implementation on some ports, and providing a null implementation on other ports. If we don't expect to add any methods there, shall I file a bug?

I think the ideal solution would be to leave out the WebSandboxSupport.h file for Android altogether as we don't need it (see the comment at WebKitPlatformSupport::sandboxSupport() [1]).
This will indeed cause errors at Chromium's side[2], for which we either have to define WebKit::WebSandboxSupport as an empty class there, or change RendererWebKitPlatformSupportImpl::SandboxSupport to not inherit from it. Either way, RendererWebKitPlatformSupportImpl::sandboxSupport should probably return NULL.

fishd, do you have a view on this? The comment states that sandboxSupport() can return NULL in case the platform doesn't need it, which is the case for Android, but current code requires the class WebKit::WebSandboxSupport to be defined.

[1] http://codesearch.google.com/#OAMlx_jo-ck/src/third_party/WebKit/Source/WebKit/chromium/public/WebKitPlatformSupport.h&l=85
[2] See renderer_webkitplatformsupport_impl.cc and ppapi_webkitplatformsupport_impl.cc

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.