Transparent fullscreen background when video is not present.
https://bugs.webkit.org/show_bug.cgi?id=135226

Patch by Jeremy Jones <jeremyj@apple.com> on 2014-07-23
Reviewed by Simon Fraser.

Set background to black just before beginning the animation to fullscreen.

* platform/ios/WebVideoFullscreenInterfaceAVKit.mm:
(WebVideoFullscreenInterfaceAVKit::enterFullscreen): set background color black.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@171506 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[iOS][WK2] r171124 is incorrect when the virtual keyboard is up
https://bugs.webkit.org/show_bug.cgi?id=135187

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

Unfortunately, restricting the input into the document rect does not work.
When the keyboard is up, the keyboard bounds can overlap the WKWebView, and
the valid range should account for that.

Instead of playing with the keyboard rect, we can limit the scroll position
inside the valid range of UIScrollView. The keyboard always adjusts the UIScrollView
range as needed to give access to the content. Using that range is a bit more permissive
because the page could scroll to reveal content in the content inset defined by the client
of the API (this could actually be quite useful for hybrid apps).

There was already a function to change the content offset in the valid scrollview
range: changeContentOffsetBoundedInValidRange(), I extracted the range check
to contentOffsetBoundedInValidRange() for the needs of -[WKWebView _scrollToContentOffset:].

So...contentOffsetBoundedInValidRange() is cool, but it is not in the right coordinate
system. The scroll position we get from the WebProcess is in document coordinates, while
contentOffsetBoundedInValidRange() works with the UIScrollView coordinates.
To fix that, we scale the input position to get to the same scale as UIScrollView, then
apply the insets with the weirdly named [WKWebView _adjustedContentOffset:].

* UIProcess/API/Cocoa/WKWebView.mm:
(contentOffsetBoundedInValidRange):
(changeContentOffsetBoundedInValidRange):
(-[WKWebView _scrollToContentOffset:]):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@171507 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[iOS WK2] Some help.apple.com pages not scrollable
https://bugs.webkit.org/show_bug.cgi?id=135228
<rdar://problem/17790792>

Reviewed by Benjamin Poulain.

On pages which size their document to the device size, the WKContentView size
never changes after it's created. In this situation, we never set a bounds
on the _rootContentView, so it remains zero-sized which breaks hit testing
on all enclosed UIScrollViews for overflow:scroll.

Fix by making the _rootContentView and the _inspectorIndicationView use autosizing
so they are always the size of their parent view, and remove the explicit setting
of their bounds.

* UIProcess/ios/WKContentView.mm:
(-[WKContentView initWithFrame:context:configuration:webView:]):
(-[WKContentView setShowingInspectorIndication:]):
(-[WKContentView _didCommitLayerTree:]):

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