Bug 191441 - [iOS] Implement safe browsing in WebKit
Summary: [iOS] Implement safe browsing in WebKit
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Alex Christensen
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2018-11-08 15:37 PST by Alex Christensen
Modified: 2018-11-13 09:16 PST (History)
3 users (show)

See Also:


Attachments
Patch (51.82 KB, patch)
2018-11-08 15:38 PST, Alex Christensen
no flags Details | Formatted Diff | Diff
Patch (53.64 KB, patch)
2018-11-09 09:09 PST, Alex Christensen
no flags Details | Formatted Diff | Diff
Patch (57.65 KB, patch)
2018-11-09 15:58 PST, Alex Christensen
no flags Details | Formatted Diff | Diff
Patch (59.10 KB, patch)
2018-11-09 21:10 PST, Alex Christensen
no flags Details | Formatted Diff | Diff
Patch (59.05 KB, patch)
2018-11-09 22:27 PST, Alex Christensen
no flags Details | Formatted Diff | Diff
Patch (59.09 KB, patch)
2018-11-09 23:01 PST, Alex Christensen
no flags Details | Formatted Diff | Diff
Patch (59.31 KB, patch)
2018-11-09 23:25 PST, Alex Christensen
no flags Details | Formatted Diff | Diff
Patch (59.27 KB, patch)
2018-11-09 23:40 PST, Alex Christensen
no flags Details | Formatted Diff | Diff
Patch (59.33 KB, patch)
2018-11-10 00:28 PST, Alex Christensen
no flags Details | Formatted Diff | Diff
Patch (49.89 KB, patch)
2018-11-12 13:51 PST, Alex Christensen
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Christensen 2018-11-08 15:37:04 PST
[iOS] Implement safe browsing in WebKit
Comment 1 Alex Christensen 2018-11-08 15:38:31 PST
Created attachment 354284 [details]
Patch
Comment 2 Alex Christensen 2018-11-08 15:39:18 PST
Comment on attachment 354284 [details]
Patch

The UI isn't quite right on this first patch, but it works!
Comment 3 Alex Christensen 2018-11-09 09:09:00 PST
Created attachment 354348 [details]
Patch
Comment 4 Alex Christensen 2018-11-09 09:09:22 PST
Comment on attachment 354348 [details]
Patch

iOS UI still isn't quite right, but much closer!
Comment 5 Alex Christensen 2018-11-09 15:58:29 PST
Created attachment 354402 [details]
Patch
Comment 6 Alex Christensen 2018-11-09 15:59:51 PST
So close!  I need to use UIUserInterfaceSizeClass instead of hard-coding a narrow width, listen for orientation transitions, and make it scroll on iOS, but other than that it's good!  Preliminary reviews welcome.
Comment 7 Alex Christensen 2018-11-09 21:10:09 PST
Created attachment 354436 [details]
Patch
Comment 8 Wenson Hsieh 2018-11-09 21:50:26 PST
Comment on attachment 354436 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=354436&action=review

> Source/WebKit/UIProcess/Cocoa/WKSafeBrowsingWarning.mm:279
> +        NSUnderlineStyleAttributeName: @(NSUnderlineStyleSingle),
> +        NSUnderlineColorAttributeName: [UIColor whiteColor],
> +        NSForegroundColorAttributeName: colorForItem(item, warning),

Nit - extra spaces after the :

> Source/WebKit/UIProcess/Cocoa/WKSafeBrowsingWarning.mm:316
> +@interface WKSafeBrowsingTextViewDelegate : NSObject<NSTextViewDelegate>

It's not common practice in ObjC to create a new instance of a class whose sole purpose is to be a delegate. I would've thought that the safe browsing view should be the text view delegate. Then, you wouldn't need this extra bit of plumbing when handling a click:

[((WKSafeBrowsingTextView *)textView)->_warning clickedOnLink:link];

> Source/WebKit/UIProcess/Cocoa/WKSafeBrowsingWarning.mm:456
> +    for (ViewType *subview in self.subviews) {

It seems strange to go digging around in the view hierarchy in search of a view that we created and added ourselves. Can we instead store a pointer to the WKSafeBrowsingTextView above and just invalidate its intrinsic content size here?

> Source/WebKit/UIProcess/Cocoa/WKSafeBrowsingWarning.mm:560
> +    constexpr auto noHeightConstraint = 1000000;

Perhaps CGFLOAT_MAX instead of an arbitrary large number?
Comment 9 Alex Christensen 2018-11-09 22:27:58 PST
Created attachment 354442 [details]
Patch
Comment 10 Alex Christensen 2018-11-09 23:01:00 PST
Created attachment 354446 [details]
Patch
Comment 11 Alex Christensen 2018-11-09 23:25:32 PST
Created attachment 354449 [details]
Patch
Comment 12 Alex Christensen 2018-11-09 23:40:08 PST
Created attachment 354450 [details]
Patch
Comment 13 Alex Christensen 2018-11-10 00:28:02 PST
Created attachment 354452 [details]
Patch
Comment 14 Tim Horton 2018-11-12 10:41:56 PST
Comment on attachment 354452 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=354452&action=review

> Source/WebKit/UIProcess/API/C/mac/WKContextPrivateMac.mm:176
> -    return DEFAULT_SAFE_BROWSING_ENABLED;
> +    return true;

Still don't understand why this doesn't follow the preference (or why you have a preference if you're not going to follow it), but OK

> Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm:3604
> +    if (_safeBrowsingWarning)

Why is this not in the Impl? This way it's going to make the eventual plop harder, and also means WKView doesn't get it.

And these aren't used on iOS so they can't be relevant to this patch.

> Source/WebKit/UIProcess/Cocoa/WKSafeBrowsingWarning.mm:169
> +    [exclamationPoint appendBezierPathWithArcWithCenter: { centerX, lineBottomCenterY } radius:lineRadius startAngle:0 endAngle:180 clockwise:YES];

Choose one space-after-colon style and stick to it (and it should be "no").
Comment 15 Alex Christensen 2018-11-12 13:51:53 PST
Created attachment 354590 [details]
Patch
Comment 16 Alex Christensen 2018-11-12 17:08:51 PST
http://trac.webkit.org/r238115
Comment 17 Radar WebKit Bug Importer 2018-11-12 17:09:21 PST
<rdar://problem/46010524>
Comment 18 Alex Christensen 2018-11-13 09:16:14 PST
http://trac.webkit.org/r238133