<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - WKView being inside WKWebView leads to weird API issues"
href="https://bugs.webkit.org/show_bug.cgi?id=150174">150174</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>WKView being inside WKWebView leads to weird API issues
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr>
<tr>
<th>Product</th>
<td>WebKit
</td>
</tr>
<tr>
<th>Version</th>
<td>WebKit Nightly Build
</td>
</tr>
<tr>
<th>Hardware</th>
<td>Unspecified
</td>
</tr>
<tr>
<th>OS</th>
<td>Unspecified
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>Normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P2
</td>
</tr>
<tr>
<th>Component</th>
<td>WebKit2
</td>
</tr>
<tr>
<th>Assignee</th>
<td>webkit-unassigned@lists.webkit.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>thorton@apple.com
</td>
</tr></table>
<p>
<div>
<pre>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?</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>