[WK2] RemoteLayerTreeDrawingAreaProxy re-checks a preference every commit for no reason
https://bugs.webkit.org/show_bug.cgi?id=134586

Reviewed by Benjamin Poulain.

* UIProcess/DrawingAreaProxy.h:
(WebKit::DrawingAreaProxy::setShouldShowDebugIndicator):
(WebKit::DrawingAreaProxy::showDebugIndicator): Deleted.
(WebKit::DrawingAreaProxy::isShowingDebugIndicator): Remove this, nobody is using it.
* UIProcess/WebPageProxy.cpp:
(WebKit::WebPageProxy::preferencesDidChange):
* UIProcess/mac/RemoteLayerTreeDrawingAreaProxy.h:
* UIProcess/mac/RemoteLayerTreeDrawingAreaProxy.mm:
(WebKit::RemoteLayerTreeDrawingAreaProxy::RemoteLayerTreeDrawingAreaProxy):
(WebKit::RemoteLayerTreeDrawingAreaProxy::commitLayerTree):
(WebKit::RemoteLayerTreeDrawingAreaProxy::setShouldShowDebugIndicator):
(WebKit::RemoteLayerTreeDrawingAreaProxy::showDebugIndicator): Deleted.
Check the debug indicator pref at construction time, and update the state when it changes.
Checking it every commit was surprisingly expensive.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@170759 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Followup to "rects sent to ServicesOverlayController are wrong"
https://bugs.webkit.org/show_bug.cgi?id=134568

Rubberstamped by Tim Horton.

* WebProcess/WebPage/mac/ServicesOverlayController.mm:
(WebKit::ServicesOverlayController::drawSelectionHighlight): Don’t check to see if the
  proposed rect intersects the dirty rect. We always need to include all rects that form
  the selection when creating the DDHighlight.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@170760 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[iOS][WK2] Sometimes the swipe snapshot stays up too long
https://bugs.webkit.org/show_bug.cgi?id=134506
<rdar://problem/17496803>

Reviewed by Simon Fraser.

Implement a transaction callback mechanism.
The UI process can register a callback at any point, generally immediately after sending a message to the Web process.
It will then send another message (in-order) with the callback ID to the Web process, which will put it into the next transaction
(scheduling a new one if needed). When the transaction comes back to the UI process, the callbacks are performed.
This ensures that the callback fires alongside a commit that includes the results of whatever messages were sent before it was registered.
For now, all callbacks are fired just before committing layer changes, but it's possible future patches will want post-commit callbacks.

Make use of this to remove the ViewGestureControllerIOS snapshots at the right time.

* Shared/mac/RemoteLayerTreeTransaction.h:
(WebKit::RemoteLayerTreeTransaction::callbackIDs):
(WebKit::RemoteLayerTreeTransaction::setCallbackIDs):
* Shared/mac/RemoteLayerTreeTransaction.mm:
(WebKit::RemoteLayerTreeTransaction::encode):
(WebKit::RemoteLayerTreeTransaction::decode):
Add a vector of callback IDs to the transaction; encode and decode as appropriate.

* UIProcess/DrawingAreaProxy.h:
(WebKit::DrawingAreaProxy::dispatchAfterEnsuringDrawing):
(WebKit::DrawingAreaProxy::lastVisibleTransactionID): Deleted.
* UIProcess/mac/RemoteLayerTreeDrawingAreaProxy.h:
* UIProcess/mac/RemoteLayerTreeDrawingAreaProxy.mm:
(WebKit::RemoteLayerTreeDrawingAreaProxy::~RemoteLayerTreeDrawingAreaProxy):
(WebKit::RemoteLayerTreeDrawingAreaProxy::commitLayerTree):
(WebKit::RemoteLayerTreeDrawingAreaProxy::dispatchAfterEnsuringDrawing):
Add dispatchAfterEnsuringDrawing, which takes a function.
When a callback is added, we send the callback ID to the Web process via the AddTransactionCallbackID message.
Perform callbacks listed in the incoming transaction's vector of callback IDs.

* WebProcess/WebPage/DrawingArea.h:
(WebKit::DrawingArea::addTransactionCallbackID):
* WebProcess/WebPage/DrawingArea.messages.in:
* WebProcess/WebPage/mac/RemoteLayerTreeDrawingArea.h:
* WebProcess/WebPage/mac/RemoteLayerTreeDrawingArea.mm:
(WebKit::RemoteLayerTreeDrawingArea::flushLayers):
(WebKit::RemoteLayerTreeDrawingArea::addTransactionCallbackID):
Keep track of the pending callback IDs on the drawing area, and move them into the transaction.
We schedule a flush when installing a transaction callback on the premise that
sometimes the action (goToBackForwardListItem in the swipe case) might have already occurred
and been committed by the time the Web process receives AddTransactionCallbackID, so we need
to cause another commit to send the callbacks across. If said commit is still pending, this is a no-op.

* UIProcess/ios/ViewGestureControllerIOS.mm:
(allViewGestureControllers):
(WebKit::ViewGestureController::ViewGestureController):
(WebKit::ViewGestureController::~ViewGestureController):
(WebKit::ViewGestureController::endSwipeGesture):
(WebKit::ViewGestureController::willCommitPostSwipeTransitionLayerTree):
(WebKit::ViewGestureController::setRenderTreeSize):
* UIProcess/mac/ViewGestureController.h:
Keep a side-map of page IDs to ViewGestureControllers, so that we can safely get back to
our ViewGestureController from the callback.

When the callback fires, if it succeeded, set m_shouldRemoveSnapshotWhenTargetRenderTreeSizeHit,
so that the commit (which is about to occur immediately after the callback returns) which calls
setRenderTreeSize will (perhaps) remove the snapshot.

If it failed, we remove the snapshot immediately, as this usually happens if the Web process crashed.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@170761 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Preserve old behavior of creating an NSURLRequest of the exact same type as passed to us
https://bugs.webkit.org/show_bug.cgi?id=134605
<rdar://problem/17544641>

Reviewed by Andreas Kling.

We have client code that passes us a subclass of NSURLRequest to load resource. Later when
we call willSendRequest, they test to make sure they get an object of the same type. My
optimization in r170642 broke this path when I cleared out the NSURLRequest object. We
already had code in updateNSURLRequest() that was taking this quirk into account but I broke
that. Fix it by reverting to old behavior for such clients.

No new tests though we need one. I will add it later.

* platform/network/cf/ResourceRequest.h:
* platform/network/cf/ResourceRequestCFNet.cpp:
(WebCore::ResourceRequest::doUpdatePlatformRequest):
(WebCore::ResourceRequest::doUpdatePlatformHTTPBody):
(WebCore::ResourceRequest::setStorageSession):
* platform/network/ios/ResourceRequestIOS.mm:
(WebCore::ResourceRequest::updateNSURLRequest):
(WebCore::ResourceRequest::clearOrUpdateNSURLRequest):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@170762 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[WK2] Revise the flat find indicator secondary highlight shadows
https://bugs.webkit.org/show_bug.cgi?id=134607
<rdar://problem/17554828>

Reviewed by Brady Eidson.

* WebProcess/WebPage/FindController.cpp:
(WebKit::FindController::drawRect):
Bring back the secondary highlight shadow, with new constants.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@170763 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Broken build with build-webkit --no-video
https://bugs.webkit.org/show_bug.cgi?id=134587

Reviewed by Darin Adler.

MEDIA_CONTROLS_SCRIPT requires VIDEO enabled.

.:
* Source/cmake/WebKitFeatures.cmake: Added the dependency for ENABLE_MEDIA_CONTROLS_SCRIPT.

Source/WTF:
* wtf/FeatureDefines.h: Added error message for dependency failure.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@170764 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Mac] WebKit1 WebView iframe not responding to scroll gestures
https://bugs.webkit.org/show_bug.cgi?id=134569
<rdar://problem/17309008>

Reviewed by Simon Fraser.


Source/WebCore: 
New test: platform/mac/fast/scrolling/scroll-iframe-fragment.html

WK1 scrollable areas are implemented on top of PlatformWidget (i.e., NSView) objects. They only
perform a scroll operation if the EventHandler::handleWheelEvent method returns 'false', indicating
that the Cocoa layer should do scrolling work. This is in contrast to WK2, where the scrolling is
handled separately and we return 'true' from EventHandler::handleWheelEvent to indicate that the
scroll event has been handled and that no other work is needed. This mismatch in the meaning of
EventHandler::handleWheelEvent means that WK1 views do not properly handle scroll wheel events.

To correct this, we need to see if we are acting on an Element backed by a PlatformWidget. When we
are (the WK1 case) we want to return 'false' to instruct the Cocoa object to do the scroll operation.
To implement proper latching behavior in WK1, we must return 'true' in the case where we are latched
to a PlatformWidget, and that PlatformWidget did not start the scroll gesture at the edge of
the region in the dominant scroll direction.

Finally, additional logic was needed to determine whether the PlatformWidget is scrolled to the
edge in the dominant scroll direction.

* page/EventHandler.cpp:
(WebCore::EventHandler::platformCompleteWheelEvent): Added stub.
(WebCore::EventHandler::platformCompletePlatformWidgetWheelEvent): Added stub.
(WebCore::EventHandler::handleWheelEvent): Call new platformCompletePlatformWidgetWheelEvent if the
event was handled for a PlatformWidget.
* page/EventHandler.h:
* page/mac/EventHandlerMac.mm:
(WebCore::widgetForEventTarget): Added helper function.
(WebCore::scrollViewForEventTarget): Added helper function.
(WebCore::eventTargetIsPlatformWidget): Added helper function.
(WebCore::EventHandler::platformPrepareForWheelEvents): Check whether we are at a scrolled edge
for the NSView (PlatformWidget) case.
(WebCore::EventHandler::platformCompleteWheelEvent): Return 'false' when handling WK1-style scrolls.
(WebCore::EventHandler::platformCompletePlatformWidgetWheelEvent): Added. We generally want to
return false so the PlatformWidget handles scrolling, except in the case where we are latched to
a PlatformWidget, which has already performed its scroll, and we want to avoid propegating a
scroll event to an enclosing region.

LayoutTests: 
* platform/mac/fast/scrolling/scroll-iframe-fragment-expected.txt: Added.
* platform/mac/fast/scrolling/scroll-iframe-fragment.html: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@170765 268f45cc-cd09-0410-ab3c-d52691b4dbfc
JSActivation::symbolTablePut() should invalidate variable watchpoints
https://bugs.webkit.org/show_bug.cgi?id=134602

Reviewed by Oliver Hunt.
        
Usually stores to captured variables cause us to invalidate the variable watchpoint because CodeBlock does so
during linking - we essentially assume that if it's at all possible for an inner function to store to a
variable we declare then this variable cannot be a constant. But this misses the dynamic store case, i.e.
JSActivation::symbolTablePut(). Part of the problem here is that JSActivation duplicates
JSSymbolTableObject's symbolTablePut() logic, which did have the invalidation. This patch keeps that code
duplicated, but fixes JSActivation::symbolTablePut() to do the right thing.

* runtime/JSActivation.cpp:
(JSC::JSActivation::symbolTablePut):
* runtime/JSSymbolTableObject.h:
(JSC::symbolTablePut):
* tests/stress/constant-closure-var-with-dynamic-invalidation.js: Added.
(.):



git-svn-id: http://svn.webkit.org/repository/webkit/trunk@170766 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Get rid of Encoder.h and Decoder.h from WTF
https://bugs.webkit.org/show_bug.cgi?id=134600

Reviewed by Darin Adler.

* WTF.vcxproj/WTF.vcxproj:
* WTF.vcxproj/WTF.vcxproj.filters:
* WTF.xcodeproj/project.pbxproj:
* wtf/Decoder.h: Removed.
* wtf/Encoder.h: Removed.

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