[iOS WK2] If a page has the exact same VisibleContentRect as the page before, its VisibleContentRectUpdate can be ignored
https://bugs.webkit.org/show_bug.cgi?id=138031
rdar://problem/18739335

Patch by Benjamin Poulain <bpoulain@apple.com> on 2014-10-23
Reviewed by Simon Fraser.

Since any VisibleContentRectUpdate is costly for the WebProcess, we avoid sending updates
if none of the important parameters have changed (scale and geometry).

One unintended side effect is that the update of a page can be blocked if the parameters
of the previous page were identical.

What happen is this:
1) Page [A] sends its content rect update as needed. WebPageProxy saves the last update
   in m_lastVisibleContentRectUpdate and use that value to avoid useless updates.
2) Page [B] load after page [A] and have the exact VisibleContentRect. When receiving the first
   layer tree commit after didCommitLoadForFrame, WKWebView sends its VisibleContentRect
   to WebPageProxy to synchronize the state of the WebProcess with what is on screen.
3) Since the two VisibleContentRect update has the same value as the ones of page [A], WebPageProxy
   discards the update. The WebProcess has its initialization viewport and is not udpated until
   a major parameter changes (scale or position).

In rdar://problem/18739335, the problem is the similar but with a different failure point:
1) Everything above happened already.
2) The layer tree transaction has a scrolling request. This is processed by WKWebView.
3) Since the scrolling position is invalid, the request is ignored and we send the last
   VisibleContentRect to the WebProcess with WebPageProxy::resendLastVisibleContentRects().
4) Since the VisibleContentRect was never updated after didCommitLoadForFrame, the one we send
   is for the previous page, which the web process correctly ignores.

This patch solves the problem by nuking the cached m_lastVisibleContentRectUpdate before
any valid VisibleContentRectUpdate for a new page.

* UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::WebPageProxy):
(WebKit::WebPageProxy::didCommitLoadForFrame):
* UIProcess/WebPageProxy.h:
* UIProcess/ios/WebPageProxyIOS.mm:
(WebKit::WebPageProxy::didCommitLayerTree):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@175153 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Mac] Optimize URL::createCFURL() for the common case
https://bugs.webkit.org/show_bug.cgi?id=138030

Reviewed by Alexey Proskuryakov.

Optimize URL::createCFURL() for the common case by adding a fast path
for when the URL String is already 8-bit (common case).
When the string is 8-bit, we don't need to copy the bytes into a
temporary buffer and we can construct the CFURLRef directly from it.

This makes URL::createCFURL() ~34% faster on my machine.

No new tests, no behavior change.

* platform/mac/URLMac.mm:
(WebCore::URL::createCFURL):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@175154 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed iOS build fix

Patch by Myles C. Maxfield <mmaxfield@apple.com> on 2014-10-23

* editing/FrameSelection.cpp:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@175155 268f45cc-cd09-0410-ab3c-d52691b4dbfc