Make WKViews work when layer-backed
Created attachment 181425 [details] Patch
<rdar://problem/12824569>
Comment on attachment 181425 [details] Patch Attachment 181425 [details] did not pass qt-wk2-ews (qt): Output: http://queues.webkit.org/results/15710561
Comment on attachment 181425 [details] Patch Attachment 181425 [details] did not pass efl-ews (efl): Output: http://queues.webkit.org/results/15703569
Created attachment 181537 [details] Patch (fixing other ports)
Thanks for the patch. If this patch contains new public API please make sure it follows the guidelines for new WebKit2 GTK+ API. See http://trac.webkit.org/wiki/WebKitGTK/AddingNewWebKit2API
Comment on attachment 181537 [details] Patch (fixing other ports) View in context: https://bugs.webkit.org/attachment.cgi?id=181537&action=review > Source/WebKit2/UIProcess/PageClient.h:93 > + // Return rue if scrollView() can copy bits in the view. > + virtual bool canScrollView() = 0; Typo: "rue". Name "can scroll view" doesn’t seem to be related to whether copying bits is OK. Can we come up with a better name? I think we’ve dealt with this elsewhere.
(In reply to comment #7) > (From update of attachment 181537 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=181537&action=review > > > Source/WebKit2/UIProcess/PageClient.h:93 > > + // Return rue if scrollView() can copy bits in the view. > > + virtual bool canScrollView() = 0; > > Typo: "rue". > > Name "can scroll view" doesn’t seem to be related to whether copying bits is OK. Can we come up with a better name? I think we’ve dealt with this elsewhere. I was following the naming of scrollView(), which I think is also confusing (in more ways than one!).
http://trac.webkit.org/changeset/138973