[Webkit-unassigned] [Bug 142387] New: REGRESSION(r181134): [GTK] Test /webkit2/WebKitWebView/insecure-content is failing after r181134

[bugzilla-daemon at webkit.org]

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

            Bug ID: 142387
           Summary: REGRESSION(r181134): [GTK] Test
                    /webkit2/WebKitWebView/insecure-content is failing
                    after r181134
    Classification: Unclassified
           Product: WebKit
           Version: 528+ (Nightly build)
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Keywords: Gtk, Regression
          Severity: Normal
          Priority: P2
         Component: Tools / Tests
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: cgarcia at igalia.com
                CC: darin at apple.com, gns at gnome.org, mcatanzaro at igalia.com,
                    mrobinson at webkit.org, oliver at apple.com,
                    svillar at igalia.com

Since r181134 we are now blocking mixed content by default (except for images if I understood the patch correctly, where we still show a warning in the console message, and the client is notified), which is indeed good news. The test is only failing for the run-insecure-content, not the display one because it uses an image. 
So, we should probably check now that the load failed in provisional load state. The thing is, since we don't expose the allowDisplayOfInsecureContent nor the allowRunningOfInsecureContent settings in the API, WEBKIT_INSECURE_CONTENT_RUN is now impossible to happen. Fortunately we didn't document any default policy in our API docs, so we can just change it, but I think we should document the new behaviour, explaining that running insecure content is always blocked, that WEBKIT_INSECURE_CONTENT_RUN is deprecated, so WebKitWebView::insecure-content-detected will only be called with WEBKIT_INSECURE_CONTENT_DISPLAYED and only for images, because all other contents will be blocked producing a load failure of the resource. 
Or we could expose the settings in our API, and keeping our current unit tests but enabling the settings (I would still keep the setting disabled by default in this case, even if it's not backwards compatible).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150306/6ae7a982/attachment-0002.html>