[Webkit-unassigned] [Bug 142469] ContentType::ActiveCanWarn should not allow bypassing allowDisplayOfInsecureContent setting

[bugzilla-daemon at webkit.org]

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

--- Comment #4 from Frédéric Wang (:fredw) <fred.wang at free.fr> ---
Thanks Michael,

(In reply to Michael Catanzaro from comment #3)
> Well, insecure content is no longer displayed, because you change
> loopback/localhost addresses to be trusted. So a test that ensures the
> insecure content warning is emitted when loading from loopback/localhost is
> expected to fail after your change.

OK, I just read https://webkit-search.igalia.com/webkit/source/Source/WebKit/UIProcess/API/gtk/WebKitWebView.h#144 and I understand better what the test is doing now. "insecure content run" or "insecure content displayed" was a bit confusing to me, I understood that this means they were *not* blocked.

> I think the only way to update the test
> would be to expose an API setting to toggle whether loopback/localhost
> addresses are trusted or not, as you've done for TestController. That would
> be overkill: it doesn't make sense to add public API solely for use by
> tests. So let's not do that.
>  * Perhaps it might be possible to allow API tests to change TestController
> settings? I don't think any tests currently attempt this, and I'm not sure
> how hard it would be.

Last week I quickly checked the API tests and didn't find any preference change in GTK. iOS/macOS do some changes and at least iOS has one API test failing, so I need to investigate this anyway.

>  * You could simply give up and remove the affected API test. But then we
> would have no tests for the insecure-content-detected signal.
>  * Finally, the best option, but also the hardest option, would be to
> modernize how WebKit handles mixed content to match Chrome's current
> behavior, which is better than ours.

That would be ideal but much bigger than bug 171934. I'm trying to do it progressively as this is touching a lot of tests and I'm not sure all ports can enable the behavior change. So I guess if changing the option does not work, I would disable the test temporarily until the rewrite.

-- 
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/20201109/d86b97bc/attachment-0001.htm>