Bug 35438 - Expose an API for ports to add schemes to the mixed content whitelist
Summary: Expose an API for ports to add schemes to the mixed content whitelist
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Other OS X 10.5
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-02-26 10:45 PST by Adam Barth
Modified: 2010-02-26 19:20 PST (History)
4 users (show)

See Also:


Attachments
Patch (3.64 KB, patch)
2010-02-26 10:47 PST, Adam Barth
no flags Details | Formatted Diff | Diff
Patch (5.68 KB, patch)
2010-02-26 15:17 PST, Adam Barth
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Barth 2010-02-26 10:45:19 PST
Chrome extensions cause "Some insecure content" on all secure pages
Comment 1 Adam Barth 2010-02-26 10:47:19 PST
Created attachment 49600 [details]
Patch
Comment 2 Darin Adler 2010-02-26 10:56:30 PST
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.
Comment 3 Adam Barth 2010-02-26 13:11:32 PST
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.
Comment 4 Sam Weinig 2010-02-26 14:20:19 PST
(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.
Comment 5 Adam Barth 2010-02-26 14:22:34 PST
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.
Comment 6 Sam Weinig 2010-02-26 14:23:39 PST
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-.
Comment 7 Adam Barth 2010-02-26 15:17:17 PST
Created attachment 49655 [details]
Patch
Comment 8 Adam Barth 2010-02-26 15:18:10 PST
+fishd for WEBKIT_API review.
Comment 9 WebKit Commit Bot 2010-02-26 19:20:27 PST
Comment on attachment 49655 [details]
Patch

Clearing flags on attachment: 49655

Committed r55335: <http://trac.webkit.org/changeset/55335>
Comment 10 WebKit Commit Bot 2010-02-26 19:20:32 PST
All reviewed patches have been landed.  Closing bug.