Expose an API for ports to add schemes to the mixed content whitelist

[Adam Barth]

Chrome extensions cause "Some insecure content" on all secure pages

[Adam Barth]

Created attachment 49600 [details]
Patch

[Darin Adler]

Comment on attachment 49600 [details]
Patch

> +#if PLATFORM(CHROMIUM)
> +        secureSchemes.add("chrome-extension");
> +#endif

Is this the right place to add this? Wouldn't this registration belong in Chromium code rather than in Chromium WebKit? I'd expect the same level that adds the extension mechanism would want to register the scheme so that other clients without the mechanism wouldn't have it registered.

[Adam Barth]

That was my original plan, but then I saw the following:

http://trac.webkit.org/browser/trunk/WebCore/page/SecurityOrigin.cpp#L57

IMHO, we shouldn't have platform-specific ifdefs in either place.

[Sam Weinig]

(In reply to comment #3)
> That was my original plan, but then I saw the following:
> 
> http://trac.webkit.org/browser/trunk/WebCore/page/SecurityOrigin.cpp#L57
> 
> IMHO, we shouldn't have platform-specific ifdefs in either place.

That could probably be turned into something we set at the WebKit layer. One difference is that applewebdata is a WebKit level thing (still admittedly a layering violation), the chrome-extensions are an Application layer thing.

[Adam Barth]

Comment on attachment 49600 [details]
Patch

Indeed.  Will spin up a new patch once I finish up what I've currently got in my tree.

[Sam Weinig]

Comment on attachment 49600 [details]
Patch

I agree with Darin, the chrome application should register the scheme.  Please file another bug about removing applewebdata from the local schemes list. r-.

[Adam Barth]

Created attachment 49655 [details]
Patch

[Adam Barth]

+fishd for WEBKIT_API review.

[WebKit Commit Bot]

Comment on attachment 49655 [details]
Patch

Clearing flags on attachment: 49655

Committed r55335: <http://trac.webkit.org/changeset/55335>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.