[WK2][WKTR] TestRunner needs to implement clearApplicationCacheForOrigin
https://bugs.webkit.org/show_bug.cgi?id=96372

Patch by Christophe Dumez <christophe.dumez@intel.com> on 2012-09-11
Reviewed by Kenneth Rohde Christiansen.

Source/WebKit2:

Add Bundle C API to clear the application cache for a
given origin. This is needed by WebKitTestRunner to
implement clearApplicationCacheForOrigin().

* WebProcess/InjectedBundle/API/c/WKBundle.cpp:
(WKBundleClearApplicationCacheForOrigin):
* WebProcess/InjectedBundle/API/c/WKBundlePrivate.h:
* WebProcess/InjectedBundle/InjectedBundle.cpp:
(WebKit::InjectedBundle::clearApplicationCacheForOrigin):
(WebKit):
* WebProcess/InjectedBundle/InjectedBundle.h:
(InjectedBundle):

Tools:

Implement clearApplicationCacheForOrigin() in WebKitTestRunner.

* WebKitTestRunner/InjectedBundle/Bindings/TestRunner.idl:
* WebKitTestRunner/InjectedBundle/TestRunner.cpp:
(WTR::TestRunner::clearApplicationCacheForOrigin):
(WTR):
* WebKitTestRunner/InjectedBundle/TestRunner.h:
(TestRunner):

LayoutTests:

Refresh Skipped list now that clearApplicationCacheForOrigin
is implemented in TestRunner. Some tests were also marked as
failing due to clearAllApplicationCaches() being missing
despite the fact that it is already implemented.

* platform/wk2/Skipped:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128173 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Qt] Add a configure step to the Qt build system

This allows building the Qt port using just 'qmake WebKit.pro'. Using
the build-webkit script is still supported, and will add slightly more
logic to the build, such as detecting the need for clean or incremental
builds.

Internally, the build system now uses a new variable, WEBKIT_CONFIG, for
all things related to configuring the build, such as use/have/enable flags,
and these are translated to defines in default_post. Project files should
no longer check contains(DEFINES,...) to detect features, but use the new
enable?(), use?(), and have?() functions. The no_webkit1 and no_webkit2
options have been translated into WEBKIT_CONFIG options as well, and can
be checked using build?().

Reviewed by Simon Hausmann.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128174 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[GTK] WebKitGtk+ crashes with non-UTF8 HTTP header names
https://bugs.webkit.org/show_bug.cgi?id=96284

Reviewed by Gustavo Noronha Silva.

Source/WebCore:

Non UTF-8 characters sent as part of a HTTP header name were
causing crashes as String::fromUTF8() was returning NULL for
them. Use String::fromUTF8WithLatin1Fallback() instead.

Test: http/tests/misc/non-utf8-header-name.php

* platform/network/soup/ResourceResponseSoup.cpp:
(WebCore::ResourceResponse::updateFromSoupMessage):

LayoutTests:

Added a new test to make sure that WebKitGtk+ does not crash when
a non-UTF8 character is sent as part of a HTTP header name.

* http/tests/misc/non-utf8-header-name-expected.txt: Added.
* http/tests/misc/non-utf8-header-name.php: Added.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128175 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Qt] Fix --qt option to build-webkit

Reviewed by Ossy.

* Scripts/webkitdirs.pm:
(buildQMakeProjects):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128176 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Qt][WK2] Page loading status API lacks a status for intentionally stopped loading
https://bugs.webkit.org/show_bug.cgi?id=83062

Patch by Marcelo Lira <marcelo.lira@openbossa.org> on 2012-09-11
Reviewed by Tor Arne Vestbø.

When the loading of a page is intentionally interrupted, the loading
status is set to the new state LoadStoppedStatus. This reflects
reality more accurately because the page was not fully loaded
(a LoadSucceededStatus), and it wasn't an unexpected error
(a LoadFailedStatus).

* UIProcess/API/qt/qquickwebview.cpp:
(QQuickWebViewPrivate::loadDidStop):
* UIProcess/API/qt/qquickwebview_p.h:
* UIProcess/API/qt/qquickwebview_p_p.h:
(QQuickWebViewPrivate):
* UIProcess/API/qt/tests/publicapi/tst_publicapi.cpp:
* UIProcess/API/qt/tests/qmltests/WebView/tst_loadUrl.qml:
* UIProcess/API/qt/tests/qmltests/common/TestWebView.qml:
* UIProcess/qt/QtWebPageLoadClient.cpp:
(WebKit::QtWebPageLoadClient::dispatchLoadStopped):
(WebKit):
(WebKit::QtWebPageLoadClient::dispatchLoadFailed):
* UIProcess/qt/QtWebPageLoadClient.h:
(QtWebPageLoadClient):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128177 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Qt] In-source builds are broken

Reviewed by Tor Arne Vestbø.

The Tools sub-directory contains a Makefile checked into SVN. For in-source builds let's not try to
overwrite it but instead generate a dedicated Makefile.Tools.

* Makefile:
* WebKit.pro:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128178 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Qt] Fix passing of defines from the build system

We explicitly have to pass -DENABLE_FOO=0 for every single feature
that's not explicitly enabled in WEBKIT_CONFIG, since Platform.h
will add it's own defaults if the features are not defined.

At some point we might want to run a configure-test to inspect what
Platform.h will do, so we can sync up the build system's view of
the feature-defines with the compile-time situation.

Reviewed by Simon Hausmann.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128179 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Qt] Fix output paths on Windows

Reviewed by Tor Arne Vestbø.

BUILD_ROOT_RELATIVE_TO_OUT_PWD was calculated incorrectly Windows, resulting in an incorrect
DESTDIR transformation at the end of default_post.prf. The calculation should be baased no qmake
paths, which can use drive letters but always use forward slashes. So the use of QMAKE_DIR_SEP is
incorrect here and instead for the calculation we should use forward slashes.

* qmake/mkspecs/features/default_pre.prf:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128180 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Tools: Support LayoutTests on non-rooted devices for Chromium Android.
https://bugs.webkit.org/show_bug.cgi?id=95346

Patch by Philippe Liard <pliard@chromium.org> on 2012-09-11
Reviewed by Dirk Pranke.

We were requiring root permissions to sync resource files with the
device by comparing host and device files' timestamp after we
synchronized the device and host clocks.
We now rely on md5sum provided by Chromium to handle data files
synchronization.

* Scripts/webkitpy/layout_tests/port/chromium.py:
(ChromiumPort._check_driver_build_up_to_date):
* Scripts/webkitpy/layout_tests/port/chromium_android.py:
(ChromiumAndroidDriver.__init__):
(ChromiumAndroidDriver._setup_test):
(ChromiumAndroidDriver._push_executable):
(ChromiumAndroidDriver._push_test_resources):
(ChromiumAndroidDriver._read_prompt):

LayoutTests: Support LayoutTests on non-rooted Android devices.
https://bugs.webkit.org/show_bug.cgi?id=95346

Patch by Philippe Liard <pliard@chromium.org> on 2012-09-11
Reviewed by Dirk Pranke.

http/tests/cache/resources/subresource-test.js was assuming that the
client and server clocks are the same which is no longer true since we
are getting rid of host/device clock synchronization.

* http/tests/cache/resources/cache-simulator.cgi:
* http/tests/cache/resources/current-time.cgi: Added.
* http/tests/cache/resources/subresource-test.js:
(getServerDate):
(nextTest):
(testComplete):
(runTests):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128181 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Blackberry] use ReadOnlyLatin1String to save a deep copy
https://bugs.webkit.org/show_bug.cgi?id=96364

Patch by Chris Guan <chris.guan@torchmobile.com.cn> on 2012-09-11
Reviewed by Yong Li.
Internally reviewed by Yong li.

* platform/network/blackberry/NetworkManager.cpp:
(WebCore::NetworkManager::startJob):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128182 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[BlackBerry] SelectionHandler drops caret change notifications
https://bugs.webkit.org/show_bug.cgi?id=96378

Reviewed by Antonio Gomes.

The selection handler deliberately drops caret change notifications
while the input handler is processing changes, to avoid displaying
intermediate state during a complex change.

However, this meant that the client was never informed of the final
caret position.

Fixed by notifying client about caret change after processing ends, if
one or more caret change notifications were dropped during processing.

PR #205073

Reviewed internally by Mike Fenton.

* WebKitSupport/InputHandler.cpp:
(BlackBerry::WebKit::InputHandler::setProcessingChange):
(WebKit):
* WebKitSupport/InputHandler.h:
(InputHandler):
* WebKitSupport/SelectionHandler.cpp:
(BlackBerry::WebKit::SelectionHandler::SelectionHandler):
(BlackBerry::WebKit::SelectionHandler::inputHandlerDidFinishProcessingChange):
(WebKit):
(BlackBerry::WebKit::SelectionHandler::selectionPositionChanged):
(BlackBerry::WebKit::SelectionHandler::notifyCaretPositionChangedIfNeeded):
* WebKitSupport/SelectionHandler.h:
(SelectionHandler):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128183 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Web Inspector: visualize layout root in Timeline
https://bugs.webkit.org/show_bug.cgi?id=96279

Reviewed by Pavel Feldman.

- pass layout root to InspectorTimelineAgent::didLayout
- show rectangles of the layout root upon hover over the Layout record;

* inspector/InspectorInstrumentation.cpp:
(WebCore):
(WebCore::InspectorInstrumentation::didLayoutImpl):
* inspector/InspectorInstrumentation.h:
(WebCore):
(InspectorInstrumentation):
(WebCore::InspectorInstrumentation::didLayout):
* inspector/InspectorTimelineAgent.cpp:
(WebCore::InspectorTimelineAgent::didLayout):
* inspector/InspectorTimelineAgent.h:
(WebCore):
(InspectorTimelineAgent):
* inspector/TimelineRecordFactory.cpp:
(WebCore::TimelineRecordFactory::createPaintData):
(WebCore::TimelineRecordFactory::addRectData):
(WebCore):
* inspector/TimelineRecordFactory.h:
(TimelineRecordFactory):
* inspector/front-end/TimelinePanel.js:
(WebInspector.TimelinePanel.prototype._mouseMove):
* page/FrameView.cpp:
(WebCore::FrameView::layout):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128184 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Qt] Fix the build with libwebp

Rubber-stamped by Tor Arne Vestbø

The use-flag is called WEBP not LIBWEBP, so use that when appending -lwebp.

* WebCore.pri:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128185 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[WK2][WTR] WebKitTestRunner needs testRunner.setSpatialNavigationEnabled
https://bugs.webkit.org/show_bug.cgi?id=96269

Patch by Mikhail Pozdnyakov <mikhail.pozdnyakov@intel.com> on 2012-09-11
Reviewed by Kenneth Rohde Christiansen.

Source/WebKit2:

Added a new setter for spacial navigation enabling to Injected Bundle private API.

* WebProcess/InjectedBundle/API/c/WKBundle.cpp:
(WKBundleSetSpatialNavigationEnabled):
* WebProcess/InjectedBundle/API/c/WKBundlePrivate.h:
* WebProcess/InjectedBundle/InjectedBundle.cpp:
(WebKit::InjectedBundle::setSpatialNavigationEnabled):
(WebKit):
* WebProcess/InjectedBundle/InjectedBundle.h:
(InjectedBundle):

Tools:

Exported missing testRunner.setSpatialNavigationEnabled() method.

* WebKitTestRunner/InjectedBundle/Bindings/TestRunner.idl:
* WebKitTestRunner/InjectedBundle/InjectedBundle.cpp:
(WTR::InjectedBundle::beginTesting):
* WebKitTestRunner/InjectedBundle/TestRunner.cpp:
(WTR::TestRunner::setSpatialNavigationEnabled):
(WTR):
* WebKitTestRunner/InjectedBundle/TestRunner.h:
(TestRunner):

LayoutTests:

Unskipped fast/spatial-navigation tests. Put those which still fail to an appropriate group.

* platform/wk2/Skipped:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128186 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Qt] Unreviewed, rolling out 128054, because it broke the Windows build.

* DerivedSources.pri:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128187 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[BlackBerry] Take account for single words that exceed our client character limit
https://bugs.webkit.org/show_bug.cgi?id=96389

Fix to the processing of long single-line text using getRangeForSpellCheckWithFineGranularity.
This was failing if a single word was longer than our maximum allowed limit.

Internally reviewed by Mike Fenton.

Patch by Nima Ghanavatian <nghanavatian@rim.com> on 2012-09-11
Reviewed by Rob Buis.

* WebKitSupport/InputHandler.cpp:
(WebKit):
(BlackBerry::WebKit::InputHandler::getRangeForSpellCheckWithFineGranularity):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128188 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Qt] [WK2] editing/inserting/typing-tab-designmode tests are failing
https://bugs.webkit.org/show_bug.cgi?id=91988

Patch by Luciano Wolf <luciano.wolf@openbossa.org> on 2012-09-11
Reviewed by Kenneth Rohde Christiansen.

Tools:

Regular key events generated by Qt for the tab key fill both
keyCode and keyText, so we should do the same for our fake events.

* WebKitTestRunner/qt/EventSenderProxyQt.cpp:
(WTR::EventSenderProxy::keyDown):

LayoutTests:

Unskip related tests.

* platform/qt-5.0-wk2/Skipped:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128189 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[WK2][WKTR] TestRunner needs to implement setApplicationCacheOriginQuota
https://bugs.webkit.org/show_bug.cgi?id=96379

Patch by Christophe Dumez <christophe.dumez@intel.com> on 2012-09-11
Reviewed by Kenneth Rohde Christiansen.

Source/WebKit2:

Add Bundle C API to set the application cache quota for a
given security origin. This is needed by WebKitTestRunner
to implement setApplicationCacheOriginQuota().

* WebProcess/InjectedBundle/API/c/WKBundle.cpp:
(WKBundleSetApplicationCacheOriginQuota):
* WebProcess/InjectedBundle/API/c/WKBundlePrivate.h:
* WebProcess/InjectedBundle/InjectedBundle.cpp:
(WebKit::InjectedBundle::setApplicationCacheOriginQuota):
(WebKit):
* WebProcess/InjectedBundle/InjectedBundle.h:
(InjectedBundle):

Tools:

Add implementation for setApplicationCacheOriginQuota
to WebKitTestRunner.

* WebKitTestRunner/InjectedBundle/Bindings/TestRunner.idl:
* WebKitTestRunner/InjectedBundle/TestRunner.cpp:
(WTR::TestRunner::setApplicationCacheOriginQuota):
(WTR):
* WebKitTestRunner/InjectedBundle/TestRunner.h:
(TestRunner):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128190 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[EFL] Rewrite the EFL-related Find modules
https://bugs.webkit.org/show_bug.cgi?id=95237

Reviewed by Kenneth Rohde Christiansen.

.:

FindEFL.cmake had several problems which caused unnecessary trouble
when building the EFL port under some setups:

o It looked for some modules (such as ecore) more than once for no
reason, which led to people adding libraries and include paths in
different ways across the build system.

o It depended on pkg-config being present for the searches to
succeed.

o It obtained the library definitions from pkg-config, so
${FOO_LIBRARIES} would be set to something like "foo;bar" which
expanded to "-lfoo -lbar" to the linker. If a wrong -L<path> was
passed before that, the wrong library installation would end up
being picked up.

o Due to the problem above, we also needed to set the LINK_FLAGS
property for each target with the value of ${FOO_LDFLAGS}, which was
also obtained from pkg-config and sort of compensated the fact that
the libraries did not use absolute paths and added the required -L
paths. This also included dependencies for these libraries, so we
ended up including libraries indirectly, which is bad.

We have now replaced that file with a set of Find-modules which are
much more granular, each of them responsible for looking for a
single library and its components and setting library and include
locations the right way (with FIND_PATH() and FIND_LIBRARY()), so
that all the problems above are fixed.

* Source/cmake/EFLHelpers.cmake: Added.
* Source/cmake/FindEDBus.cmake: Added.
* Source/cmake/FindEFL.cmake: Removed.
* Source/cmake/FindEcore.cmake: Added.
* Source/cmake/FindEdje.cmake: Added.
* Source/cmake/FindEeze.cmake: Added.
* Source/cmake/FindEfreet.cmake: Added.
* Source/cmake/FindEina.cmake: Added.
* Source/cmake/FindEvas.cmake: Added.
* Source/cmake/OptionsEfl.cmake:

Source/JavaScriptCore:

* CMakeLists.txt: Stop setting the LINK_FLAGS property.
* PlatformEfl.cmake: Ditto.
* shell/PlatformEfl.cmake: Ditto.

Source/WebCore:

* CMakeLists.txt: Stop setting the LINK_FLAGS property now that no
port sets WebCore_LINK_FLAGS.
* PlatformEfl.cmake: Add libraries and include directories for
each Enlightenment Foundation Library used by the port.

Source/WebKit:

* PlatformEfl.cmake: Stop setting the LINK_FLAGS property and add
libraries and include directories for each Enlightenment
Foundation Library used by the port.

Source/WebKit2:

* CMakeLists.txt: Stop setting the LINK_FLAGS property.
* PlatformEfl.cmake: Add libraries and include directories for
each Enlightenment Foundation Library used by the port.

Source/WTF:

* CMakeLists.txt: Stop setting the LINK_FLAGS property.
* PlatformEfl.cmake: Add libraries and include directories for
each Enlightenment Foundation Library used by the port.

Tools:

* DumpRenderTree/efl/CMakeLists.txt: Stop setting the LINK_FLAGS
property and include all the Enlightenment Foundation Libraries
required by the target.
* EWebLauncher/CMakeLists.txt: Ditto.
* MiniBrowser/efl/CMakeLists.txt: Ditto.
* TestWebKitAPI/PlatformEfl.cmake: Add missing include directories
now that they are not added implicitly.
* WebKitTestRunner/CMakeLists.txt: Stop setting the LINK_FLAGS
property.
* WebKitTestRunner/PlatformEfl.cmake: Stop setting the LINK_FLAGS
property and include all the Enlightenment Foundation Libraries
required by the target.

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@128191 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed, rolling out r128175.
http://trac.webkit.org/changeset/128175
https://bugs.webkit.org/show_bug.cgi?id=96395

broke hunders of tests for EFL and GTK (Requested by rakuco on
#webkit).

Patch by Sheriff Bot <webkit.review.bot@gmail.com> on 2012-09-11

Source/WebCore:

* platform/network/soup/ResourceResponseSoup.cpp:
(WebCore::ResourceResponse::updateFromSoupMessage):

LayoutTests:

* http/tests/misc/non-utf8-header-name-expected.txt: Removed.
* http/tests/misc/non-utf8-header-name.php: Removed.

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