WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED WONTFIX
71948
[GTK][WK1] Expose API for choice of displaying/running insecure content
https://bugs.webkit.org/show_bug.cgi?id=71948
Summary
[GTK][WK1] Expose API for choice of displaying/running insecure content
Zan Dobersek
Reported
2011-11-09 13:18:26 PST
API should be exposed to offer to developers a path of providing a user with a choice of whether or not to load and display/run insecure content. Implementation will be based upon policy decisions.
Attachments
Patch
(35.00 KB, patch)
2011-11-11 12:57 PST
,
Zan Dobersek
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Zan Dobersek
Comment 1
2011-11-11 11:59:36 PST
I've come to realization that this bug doesn't really cover the needs of
bug #71465
. This bug oversees addition of API for policy decision requests about displaying or running insecure content, which is a part of methods used in FrameLoader class, while didDetectXSS originates from the HTML parser. I'll create a new meta bug with the goal of improving security-related API, remove this bug from blocking #71465 and set both of these to block the new bug.
Zan Dobersek
Comment 2
2011-11-11 12:57:57 PST
Created
attachment 114755
[details]
Patch When landed, DumpRenderTree should also require an update, setting the new WebKitWebSettings properties to true. Not flagging for commit queue for now.
Zan Dobersek
Comment 3
2011-11-13 09:02:24 PST
(In reply to
comment #2
)
> Created an attachment (id=114755) [details] > Patch > > When landed, DumpRenderTree should also require an update, setting the new WebKitWebSettings properties to true. Not flagging for commit queue for now.
Should I also add in this patch signals that would be emitted from FrameLoaderClient::didDisplayInsecureContent and FrameLoaderClient::didRunInsecureContent? The whole patch and API was developed along with adding this feature to epiphany. If there's interest, I can later put a patch up on GNOME bugzilla.
Zan Dobersek
Comment 4
2012-05-14 12:07:36 PDT
Given the focus is now shifting towards WebKit2 APIs and WebKit2 in general, meaning new API additions to WebKit1 don't really make sense, I'm willing to close this bug as a WONTFIX. I'll do so after I get some additional thumbs-ups in agreement.
Martin Robinson
Comment 5
2012-05-14 12:50:06 PDT
Sure. I'd be happy to review this patch for WebKit2.
Zan Dobersek
Comment 6
2012-05-16 12:48:15 PDT
(In reply to
comment #5
)
> Sure. I'd be happy to review this patch for WebKit2.
I've added an API todo task:
http://trac.webkit.org/wiki/WebKitGTK/WebKit2Roadmap?action=diff&version=35
Closing this as a WONTFIX.
Eric Seidel (no email)
Comment 7
2012-05-21 15:11:51 PDT
Comment on
attachment 114755
[details]
Patch Cleared review? from
attachment 114755
[details]
so that this bug does not appear in
http://webkit.org/pending-review
. If you would like this patch reviewed, please attach it to a new bug (or re-open this bug before marking it for review again).
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug