[Webkit-unassigned] [Bug 150174] New: WKView being inside WKWebView leads to weird API issues

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Oct 15 09:43:15 PDT 2015


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

            Bug ID: 150174
           Summary: WKView being inside WKWebView leads to weird API
                    issues
    Classification: Unclassified
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKit2
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: thorton at apple.com

Having a WKView nested inside a WKWebView causes fun but subtle troubles, most frequently regarding overriding NSResponder methods; if the WKView eats the event, the client's override on WKWebView has no effect. Also, I slightly fear clients noticing that there's a WKView in there and doing... things... to it that they otherwise shouldn't/can't.

As we all know, every problem in software can be solved by another layer of abstraction, so I propose we move all of the code backing WKView to a new class (I've called it WebViewImpl for now), forwarding externally-facing WKView API *directly* to the new class, without any logic at all in WKView. Then, for whatever externally-facing WKWebView API we wish to expose, we can also call straight into WebViewImpl, and avoid duplication of any interesting logic.

WebViewImpl will be a C++ class, which confers two interesting benefits: 1) it will make mistakes during translation obvious, because 'self' is meaningless, so we'll have to reason about each of those individually, and 2) WebViewImpl and PageClientImpl can eventually merge, which will allow a bit /less/ indirection in the case of WebPageProxy asking a question WebViewImpl knows how to answer directly.

This also provides an opportunity to take a careful stroll through the mass of code that is WKView and clean things up... yay?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20151015/8ec45476/attachment.html>


More information about the webkit-unassigned mailing list