Bug 178240

Summary: Expose some of WKView's WebViewImpl accessors through WKWebViewPrivate
Product: WebKit Reporter: Alex Christensen <achristensen>
Component: New BugsAssignee: Alex Christensen <achristensen>
Status: RESOLVED FIXED    
Severity: Normal CC: jeffm, mitz, simon.fraser, thorton
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch
none
Patch thorton: review+

Alex Christensen
Reported 2017-10-12 15:52:07 PDT
Expose some of WKView's WebViewImpl accessors through WKWebViewPrivate
Attachments
Patch (10.54 KB, patch)
2017-10-12 15:55 PDT, Alex Christensen
no flags
Patch (13.78 KB, patch)
2017-10-12 17:22 PDT, Alex Christensen
no flags
Patch (14.66 KB, patch)
2017-10-12 17:27 PDT, Alex Christensen
thorton: review+
Alex Christensen
Comment 1 2017-10-12 15:55:27 PDT
Jeff Miller
Comment 2 2017-10-12 16:32:26 PDT
Jeff Miller
Comment 3 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.
Alex Christensen
Comment 4 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.
Simon Fraser (smfr)
Comment 5 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.
Tim Horton
Comment 6 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.
Alex Christensen
Comment 7 2017-10-12 17:22:17 PDT
Alex Christensen
Comment 8 2017-10-12 17:27:14 PDT
Alex Christensen
Comment 9 2017-10-12 17:41:58 PDT
mitz
Comment 10 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?
Note You need to log in before you can comment on or make changes to this bug.