[Mac] hasVideo should return true when video is ready to display
https://bugs.webkit.org/show_bug.cgi?id=132885

Reviewed by Jer Noble.

* html/HTMLMediaElement.cpp:
(WebCore::HTMLMediaElement::parseAttribute):

* platform/graphics/avfoundation/objc/AudioTrackPrivateAVFObjC.mm:
(WebCore::AudioTrackPrivateAVFObjC::resetPropertiesFromTrack): Don't change the
    enabled state of the AVPlayerItemTrack during setup.

* platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.h:
* platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.mm:
(WebCore::MediaPlayerPrivateAVFoundationObjC::MediaPlayerPrivateAVFoundationObjC): Initialize
    m_cachedIsReadyForDisplay.
(WebCore::MediaPlayerPrivateAVFoundationObjC::cancelLoad): Remove "enabled" KVO observers.
(WebCore::MediaPlayerPrivateAVFoundationObjC::createVideoLayer): Observe "readyForDisplay"
    change notifications.
(WebCore::MediaPlayerPrivateAVFoundationObjC::destroyVideoLayer): Remove for "readyForDisplay"
    observer.
(WebCore::MediaPlayerPrivateAVFoundationObjC::hasAvailableVideoFrame): Return cached readyForDisplay
    state instead of polling every time.
(WebCore::MediaPlayerPrivateAVFoundationObjC::tracksChanged): Call setHasVideo(true) if the
    player layer is ready for display.
(WebCore::MediaPlayerPrivateAVFoundationObjC::updateAudioTracks): Update logging.
(WebCore::MediaPlayerPrivateAVFoundationObjC::updateVideoTracks): Ditto.
(WebCore::MediaPlayerPrivateAVFoundationObjC::firstFrameAvailableDidChange): Cache readyForDisplay
    state, call tracksChanged() if we haven't seen a video track yet.
(WebCore::MediaPlayerPrivateAVFoundationObjC::trackEnabledDidChange): New.
(WebCore::MediaPlayerPrivateAVFoundationObjC::metadataDidArrive): Correct logging.
(WebCore::MediaPlayerPrivateAVFoundationObjC::tracksDidChange): Remove old "enabled" listeners
    before release tracks, add new ones to new tracks.
(WebCore::assetTrackMetadataKeyNames): Add "enabled" to the list of properties we require to 
    be loaded before announcing that metadata has loaded.
(-[WebCoreAVFMovieObserver observeValueForKeyPath:ofObject:change:context:]): Observe 
    "readyForDisplay" and "enabled".

* platform/graphics/avfoundation/objc/VideoTrackPrivateAVFObjC.cpp:
(WebCore::VideoTrackPrivateAVFObjC::resetPropertiesFromTrack): Don't change the
    enabled state of the AVPlayerItemTrack during setup.


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

* platform/graphics/avfoundation/objc/MediaPlayerPrivateAVFoundationObjC.mm:
(WebCore::MediaPlayerPrivateAVFoundationObjC::metadataDidArrive):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@168758 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[iOS] Page scale update messages for media controls should only fire at the end of zooming
https://bugs.webkit.org/show_bug.cgi?id=132857
<rdar://problem/16631009>

Reviewed by Simon Fraser.

As the user was zooming, the media controls that responded
to the page scale (and resized themselves) would do so
slightly out of sync with the screen refreshes, and it looked

Source/WebCore:
terrible. They really only need to get told at the end
of the zoom that they need to relayout.

Allow setPageScaleFactor to accept another parameter
that indicates if the change is stable. That way, changes
during a user triggers zoom gesture can be ignored for
media controls.

* WebCore.exp.in: Page::setPageScaleFactor takes a new parameter.
* dom/Document.cpp:
(WebCore::Document::pageScaleFactorChangedAndStable): Renamed from pageScaleFactorChanged.
(WebCore::Document::pageScaleFactorChanged): Deleted.
* dom/Document.h:
* page/Page.cpp:
(WebCore::Page::setPageScaleFactor): Accepts a new inStableState parameter,
and tells the main frame that the scale factor has changed if it's stable.
* page/Page.h:

Source/WebKit2:
terrible.

We already know if a pageScale change is happening inside
a gesture using the inStableState property of the visibleContentRectUpdateInfo.
Simply pass this along to WebCore::Page.

* WebProcess/WebPage/ios/WebPageIOS.mm:
(WebKit::WebPage::updateVisibleContentRects): Pass inStableState onto the
WebCore::Page. Note that we have to send this message even if the
scale has not changed, since the last changing update might not have
been stable.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@168761 268f45cc-cd09-0410-ab3c-d52691b4dbfc
REGRESSION (topContentInset): Searching through Facebook Messenger's chat causes 
scrolling in News Feed
https://bugs.webkit.org/show_bug.cgi?id=132889
-and corresponding-
<rdar://problem/16715716>

Reviewed by Simon Fraser.


Source/WebCore: 
First of all, scrollOffsetRelativeToDocument() was very poorly named. This patch 
re-names it to the much more accurate documentScrollOffsetRelativeToViewOrigin(). 
Re-naming it makes it clear that ONE call site was not getting the right offset. 
That call site does not want to know the document’s position relative to the view 
origin, but rather it wants to know the Document’s position relative to the 
scrolling origin.

Export new name.
* WebCore.exp.in:

Use newly re-named documentScrollPositionRelativeToViewOrigin().
* page/FrameView.cpp:
(WebCore::FrameView::convertToRenderer):
* platform/ScrollView.cpp:
(WebCore::ScrollView::documentScrollOffsetRelativeToViewOrigin):
(WebCore::ScrollView::documentScrollPositionRelativeToViewOrigin):
(WebCore::ScrollView::documentScrollOffsetRelativeToScrollableAreaOrigin):
(WebCore::ScrollView::rootViewToContents):
(WebCore::ScrollView::windowToContents):
(WebCore::ScrollView::scrollOffsetRelativeToDocument): Deleted.
(WebCore::ScrollView::scrollPositionRelativeToDocument): Deleted.
* platform/ScrollView.h:

THIS is the spot that needs the new function, 
documentScrollOffsetRelativeToScrollableAreaOrigin()()
* rendering/RenderLayer.cpp:
(WebCore::RenderLayer::scrollRectToVisible):

Source/WebKit2: 
Re-name scrollOffsetRelativeToDocument() to 
documentScrollPositionRelativeToViewOrigin().
* WebProcess/WebPage/FindController.cpp:
(WebKit::FindController::rectsForTextMatches):
* WebProcess/WebPage/WebPage.cpp:
(WebKit::WebPage::determinePrimarySnapshottedPlugIn):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@168763 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Force developerExtrasEnabled when a remote Inspector client connects.

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

Reviewed by Joseph Pecoraro.

* page/PageDebuggable.cpp:
(WebCore::PageDebuggable::PageDebuggable): Initialize m_forcedDeveloperExtrasEnabled to false.
(WebCore::PageDebuggable::connect): Set m_forcedDeveloperExtrasEnabled if the setting is changed.
(WebCore::PageDebuggable::disconnect): Switch developerExtrasEnabled back to false
if m_forcedDeveloperExtrasEnabled is true.
* page/PageDebuggable.h: Added m_forcedDeveloperExtrasEnabled.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@168764 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Step 1 of fixing the windows build. Remove setPageScaleFactor.

* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@168765 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Step 2 (of 2) fixing the Windows build. Add new setPageScaleFactor.

* WebKit.vcxproj/WebKitExportGenerator/WebKitExports.def.in:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@168766 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Attempted build fix after https://bugs.webkit.org/show_bug.cgi?id=132891

* page/PageDebuggable.cpp:

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

Reviewed by Dan Bernstein.

* Shared/API/Cocoa/WKFoundation.h:
Make sure to include Availability.h

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