Bug 178240 - Expose some of WKView's WebViewImpl accessors through WKWebViewPrivate
Summary: Expose some of WKView's WebViewImpl accessors through WKWebViewPrivate
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: 2017-10-12 15:52 PDT by Alex Christensen
Modified: 2018-01-27 10:16 PST (History)
4 users (show)

See Also:


Attachments
Patch (10.54 KB, patch)
2017-10-12 15:55 PDT, Alex Christensen
no flags Details | Formatted Diff | Diff
Patch (13.78 KB, patch)
2017-10-12 17:22 PDT, Alex Christensen
no flags Details | Formatted Diff | Diff
Patch (14.66 KB, patch)
2017-10-12 17:27 PDT, Alex Christensen
thorton: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Christensen 2017-10-12 15:52:07 PDT
Expose some of WKView's WebViewImpl accessors through WKWebViewPrivate
Comment 1 Alex Christensen 2017-10-12 15:55:27 PDT
Created attachment 323583 [details]
Patch
Comment 2 Jeff Miller 2017-10-12 16:32:26 PDT
rdar://problem/34962720
Comment 3 Jeff Miller 2017-10-12 16:33:05 PDT
Can you add the immediate action methods as well?

- (void)_prepareForImmediateActionAnimation;
- (void)_cancelImmediateActionAnimation;
- (void)_completeImmediateActionAnimation;

These methods are overridden in Safari, so the fact that they are no-ops in WebKit is misleading. We need WebKit to invoke these methods at the right time in WKWebView, e.g.:

- (void)_web_prepareForImmediateActionAnimation
{
    [self _prepareForImmediateActionAnimation];
}

Currently, _web_prepareForImmediateActionAnimation/_web_cancelImmediateActionAnimation/_web_completeImmediateActionAnimation do nothing in WKWebView, unlike WKView.
Comment 4 Alex Christensen 2017-10-12 16:43:44 PDT
Behavior equivalent to WKView can already be achieved by overriding _web_prepareForImmediateActionAnimation et al. in subclasses, so those are not blocking.  We aren't going to add yet another layer of selectors that do nothing but call selectors because a subclass may have overridden it.  Those will be added as WKUIDelegatePrivate callbacks when we decide to organize this in a sane way.
Comment 5 Simon Fraser (smfr) 2017-10-12 16:49:48 PDT
Comment on attachment 323583 [details]
Patch

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

> Source/WebKit/UIProcess/API/Cocoa/WKWebViewPrivate.h:403
> +@property (copy, nonatomic, setter=_setUnderlayColor:) NSColor *_underlayColor;

Can we put the nonatomic first, like the others? Also would be nice to group this with the the properties below.
Comment 6 Tim Horton 2017-10-12 16:55:53 PDT
(In reply to Alex Christensen from comment #4)
> Behavior equivalent to WKView can already be achieved by overriding
> _web_prepareForImmediateActionAnimation et al. in subclasses, so those are
> not blocking.  We aren't going to add yet another layer of selectors that do
> nothing but call selectors because a subclass may have overridden it.  Those
> will be added as WKUIDelegatePrivate callbacks when we decide to organize
> this in a sane way.

I think we don't need these to be _web_ things, since they call self, not super -- we can just call the real thing (without the _web prefix) from WebViewImpl.
Comment 7 Alex Christensen 2017-10-12 17:22:17 PDT
Created attachment 323607 [details]
Patch
Comment 8 Alex Christensen 2017-10-12 17:27:14 PDT
Created attachment 323608 [details]
Patch
Comment 9 Alex Christensen 2017-10-12 17:41:58 PDT
http://trac.webkit.org/r223267
Comment 10 mitz 2018-01-27 10:16:42 PST
Comment on attachment 323608 [details]
Patch

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

> Source/WebKit/UIProcess/API/Cocoa/WKWebViewPrivate.h:408
> +@property (nonatomic, copy, setter=_setUnderlayColor:) NSColor *_underlayColor;

Why is this one not annotated with availability?