[WK2] Push wheel events if there are too many in queue
https://bugs.webkit.org/show_bug.cgi?id=85747
<rdar://problem/11390790>

Reviewed by Anders Carlsson.

It is possible that a whole bunch of messages added to the message queue, or a series
of long-running messages, cause unresponsiveness. The reason for this is that we have
a scroll event waiting for acknowledgment from the web process before it sends the next
event. And in the time between the user has scrolled, causing a large backlog of scroll
events to be held in the UI process.

We should push new scroll events if the queue accumulates too many of them.

* UIProcess/WebPageProxy.h: The vector m_currentlyProcessedWheelEvents used to hold the
series of wheel events that were coalesced and sent as a single wheel event to the web
process. When the web process acknowledges this with didReceiveEvent, the UI process
cleared that vector, then tried to coalesce the next wheel event to send. Now we might have
multiple sets of coalesced wheel events that we are sending to the web process. To keep
track of these sets, m_currentlyProcessedWheelEvents now is a queue of Vectors.
(WebPageProxy):
* UIProcess/WebPageProxy.cpp: Add new constant wheelEventQueueSizeThreshold representing
the threshold of scroll events to look for before we start pushing events.
(WebKit::canCoalesce): Move static function so that handleWheelEvent() has access. No changes.
(WebKit::coalesce): Move static function so that handleWheelEvent() has access. No changes.
(WebKit::coalescedWheelEvent): Move static function so that handleWheelEvent() has access. No changes.
(WebKit::WebPageProxy::handleWheelEvent): If we are currently waiting for acknowledgment
from the web process that a wheel event has been handled, we add it to the queue. We
check to see that the queue size is within our threshold before we return early. Otherwise
we will start pushing events in the queue. Refactor the rest of the function into
processNextQueuedWheelEvent() and sendWheelEvent(). If we are not currently waiting for
acknowledgment, nor have events in the queue, then we send the current wheel event.
(WebKit::WebPageProxy::processNextQueuedWheelEvent): Try to coalesce events based on the
wheel event at the head of the queue, and send that event to the web process.
(WebKit::WebPageProxy::sendWheelEvent): Refactored from handleWheelEvent().
(WebKit::WebPageProxy::didReceiveEvent): Instead of clearing m_currentlyProcessedWheelEvents,
which contained the set of one coalesced wheel event, we pull the head Vector, which
contains the same set of events. Refactor to use processNextQueuedWheelEvent().

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@116466 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[CMake] FindGStreamer: Fix the build with static WebCore.
https://bugs.webkit.org/show_bug.cgi?id=85930

Reviewed by Daniel Bates.

.:

Building WebCore statically was failing because files in
WebCore/platform/gstreamer when ENABLE_VIDEO was set required
gstreamer-base, which was not being linked to after r116453.

Fix that by looking for gstreamer-base, requiring and linking
against it if GStreamer is used.

* Source/cmake/FindGStreamer.cmake:

Source/WebCore:

No new tests, build fix.

Building WebCore statically was failing because files in
WebCore/platform/gstreamer when ENABLE_VIDEO was set required
gstreamer-base, which was not being linked to after r116453.

Fix that by looking for gstreamer-base, requiring and linking
against it if GStreamer is used.

* PlatformEfl.cmake: Link to GSTREAMER_LIBRARIES and
GSTREAMER_BASE_LIBRARIES, and include GSTREAMER_INCLUDE_DIRS and
GSTREAMER_BASE_INCLUDE_DIRS.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@116468 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Can't scroll PDF in subframe
https://bugs.webkit.org/show_bug.cgi?id=85932
<rdar://problem/11405527>

Reviewed by Sam Weinig.

* WebProcess/Plugins/PDF/BuiltInPDFView.h:
* WebProcess/Plugins/PDF/BuiltInPDFView.mm:
(WebKit::BuiltInPDFView::updateScrollbars):
Trigger a layout when scrollbars come and go so the non fast scrollable region gets recomputed.

(WebKit::BuiltInPDFView::scrollableAreaBoundingBox):
Implement this by calling out to the PluginView.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@116469 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[EFL] Pass a WTF::String directly from DRT to ewebkit when possible
https://bugs.webkit.org/show_bug.cgi?id=84634

Reviewed by Gustavo Noronha Silva.

Drop unnecessary const char* -> WTF::String conversions by
creating String objects directly in LayoutTestController out of
JSStringRef's and passing them to DumpRenderTreeSupportEfl.

Source/WebKit/efl:

* WebCoreSupport/DumpRenderTreeSupportEfl.cpp:
(DumpRenderTreeSupportEfl::setValueForUser):
(DumpRenderTreeSupportEfl::addUserStyleSheet):
(DumpRenderTreeSupportEfl::findString):
* WebCoreSupport/DumpRenderTreeSupportEfl.h:

Tools:

* DumpRenderTree/efl/LayoutTestControllerEfl.cpp:
(LayoutTestController::queueLoad):
(LayoutTestController::setValueForUser):
(LayoutTestController::findString):
(LayoutTestController::addUserStyleSheet):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@116470 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Add stylesheet inheritance support to IFRAME_SEAMLESS
https://bugs.webkit.org/show_bug.cgi?id=85914

Reviewed by Ojan Vafai.

Source/WebCore:

This work is already guarded by IFRAME_SEAMLESS, as
Document::shouldDisplaySeamlesslyWithParent always returns false
when IFRAME_SEAMLESS is off.

This makes the child document use all author stylesheets from all parent documents,
per the seamless spec:
http://www.whatwg.org/specs/web-apps/current-work/#attr-iframe-seamless

This support is slightly inefficient as every time a sheet is added
to a parent document, the child document must do a full style selector recalc.
Normally author sheet additions have a fast-path which avoids the full selector recalc,
but such is not possible in the seamless case as we're inserting the parents sheets
earlier in the child's cascade (instead of just appending them to the end of the list).

The test covers both the static inheritance as well as addition of a stylesheet
to the parent and testing that it caused a recalc of the child.

Covered by fast/frames/seamless/seamless-css-cascade.html

* css/StyleResolver.cpp:
(WebCore::StyleResolver::StyleResolver):
(WebCore::StyleResolver::addStylesheetsFromSeamlessParents):
(WebCore):
* css/StyleResolver.h:
(StyleResolver):
* dom/Document.cpp:
(WebCore::Document::seamlessParentUpdatedStylesheets):
(WebCore):
(WebCore::Document::notifySeamlessChildDocumentsOfStylesheetUpdate):
(WebCore::Document::updateActiveStylesheets):
* dom/Document.h:
(Document):

LayoutTests:

Update the results (for both static and dynamic inheritance)
now that this support is landed.

* fast/frames/seamless/seamless-css-cascade-expected.txt:


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@116471 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[chromium] Reflections with masks should not occlude
https://bugs.webkit.org/show_bug.cgi?id=85927

Reviewed by James Robinson.

Source/WebCore:

When a surface does not have a mask, we make both it and its reflection
occlude the things below them. However, if the reflection has a mask
applied to it, then we should not consider it as occluding.

Adds replicaHasMask() to the render surface classes so we can test if
the mask is present.

Unit Tests: CCOcclusionTrackerTestReplicaWithMask

* platform/graphics/chromium/RenderSurfaceChromium.cpp:
(WebCore::RenderSurfaceChromium::hasMask):
This is unusued right now, but will allow us to remove a FIXME from
CCOcclusionTracker::finishedTargetRenderSurface().
(WebCore):
(WebCore::RenderSurfaceChromium::replicaHasMask):
* platform/graphics/chromium/RenderSurfaceChromium.h:
(RenderSurfaceChromium):
* platform/graphics/chromium/cc/CCOcclusionTracker.cpp:
(WebCore::::leaveToTargetRenderSurface):
* platform/graphics/chromium/cc/CCRenderSurface.cpp:
(WebCore::CCRenderSurface::hasMask):
This is unusued right now, but will allow us to remove a FIXME from
CCOcclusionTracker::finishedTargetRenderSurface().
(WebCore):
(WebCore::CCRenderSurface::replicaHasMask):
* platform/graphics/chromium/cc/CCRenderSurface.h:
(CCRenderSurface):

Source/WebKit/chromium:

* tests/CCOcclusionTrackerTest.cpp:
(WebKitTests::CCOcclusionTrackerTest::TearDown):
(WebKitTests::CCOcclusionTrackerTest::createMaskLayer):
(CCOcclusionTrackerTest):
(WebKitTests::CCOcclusionTrackerTest::setMask):
(CCOcclusionTrackerTestReplicaWithMask):
(WebKitTests::CCOcclusionTrackerTestReplicaWithMask::runMyTest):
(WebKitTests):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@116472 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Safari warns that it needs to resend the form in an iFrame when going back
https://bugs.webkit.org/show_bug.cgi?id=82658
<rdar://problem/11292558>

Reviewed by Darin Adler.

Source/WebCore:

Test: http/tests/loading/post-in-iframe-with-back-navigation.html

* WebCore.exp.in: Add _wkCFURLRequestAllowAllPostCaching.
* platform/mac/WebCoreSystemInterface.h: Add wkCFURLRequestAllowAllPostCaching.
* platform/mac/WebCoreSystemInterface.mm: Add wkCFURLRequestAllowAllPostCaching.
* platform/network/cf/ResourceRequestCFNet.cpp:
(WebCore::ResourceRequest::doUpdatePlatformRequest): Set the bit to cache all POST responses.
* platform/network/mac/ResourceRequestMac.mm:
(WebCore::ResourceRequest::doUpdatePlatformRequest): Set the bit to cache all POST responses.

Source/WebKit/mac:

* WebCoreSupport/WebSystemInterface.mm:
(InitWebCoreSystemInterface): Add wkCFURLRequestAllowAllPostCaching.

Source/WebKit2:

* WebProcess/WebCoreSupport/mac/WebSystemInterface.mm:
(InitWebCoreSystemInterface): Add wkCFURLRequestAllowAllPostCaching.

WebKitLibraries:

* WebKitSystemInterface.h:
* libWebKitSystemInterfaceLeopard.a:
* libWebKitSystemInterfaceLion.a:
* libWebKitSystemInterfaceSnowLeopard.a:

LayoutTests:

Add new test which navigates a series of pages in an iframe. Each navigation is a POST.
At the third page we click on a back link, and expect to see stale POST data.

* http/tests/loading/post-in-iframe-with-back-navigation-expected.txt: Added.
* http/tests/loading/post-in-iframe-with-back-navigation.html: Added.
* http/tests/loading/resources/post-in-iframe-with-back-navigation-page-1.php: Added.
* http/tests/loading/resources/post-in-iframe-with-back-navigation-page-2.php: Added.
* http/tests/loading/resources/post-in-iframe-with-back-navigation-page-3.php: Added.
* http/tests/resources/js-test-post.js: Added. Copied from fast/js/resources since it is
inaccessible to the test server.
* http/tests/resources/js-test-pre.js: Added. Copied from fast/js/resources since it is
inaccessible to the test server.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@116473 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[chromium] force ENABLE_REGISTER_PROTOCOL_HANDLER=1 in features.gypi
https://bugs.webkit.org/show_bug.cgi?id=85924

Reviewed by Adam Barth.

This has been enabled for a few months on Chromium trunk so remove the
ability to turn it off via a gyp flag. This simplifies features.gypi.

* features.gypi:


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