[Webkit-unassigned] [Bug 200398] Add an SPI to suppress all WKWebView interactions except scrolling or zooming

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sun Aug 4 15:29:16 PDT 2019


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

--- Comment #10 from Luming Yin <luming_yin at apple.com> ---
(In reply to Geoffrey Garen from comment #9)
> > It seems the SPI client invokes this when it wishes to begin temporarily
> > begin suppressing certain types of interaction in the web view until the
> > next user gesture — for instance, scrolling, pinching, tapping, or long
> > pressing. When such a gesture happens, the completion handler passed in by
> > the client is then invoked.
> > 
> > This means the call to -_restoreAllInteractions is actually optional, and
> > only allows the client to stop suppressing interactions prematurely.
> 
> I missed this detail the first time around. It's nice that the
> implementation automatically restores interaction upon the first
> interaction. That helps.
> 
> Even so, it looks like long press and context menu will not automatically
> restore? So there is still some risk here.
Long press and context menu will automatically restore if a tap, scroll or pinch is detected. Since 
any of the above would call -_setSuppressInteractionsExceptScrollingOrZooming:NO, 
_setSuppressInteractionsExceptScrollingOrZooming sets the ivar _suppressInteractions to be NO, and 
sets _webView.configuration._longPressActionsEnabled to YES. 

In other words, when long presses are suppressed, it would be picked up by _singleTapGestureRecognizer 
instead, which will restore everything.

> 
> > > (2) Instead of accepting a BOOL argument, return a token object, which
> > > offers a -cancel method, and which also calls -cancel automatically in its
> > > -dealloc method;
> 
> Looking at the described used case, and at the implementation here, I do
> still think that a token object that held a -cancel method and a
> completionHandler would be a nice way to model this behavior. (Specifically,
> I would have WebKit hold a weak reference to the token, and the client hold
> a strong reference.)
> 
> This suppression is associated with a specific object in the client, so that
> object can own the token object.
Makes sense, and thanks for the extra notes on object ownership. I'll look into returning a token 
object with a cancel method and a completionHandler instead.

-- 
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/20190804/45383c2f/attachment-0001.html>


More information about the webkit-unassigned mailing list