[Qt] QRawWebView should notify when rendering is done, so that pixel results can be grabbed at the appropriate moment.
https://bugs.webkit.org/show_bug.cgi?id=90641

Reviewed by Jocelyn Turcotte.

Source/WebKit2:

Implement LayerTreeCoordinator::forceRepaint with logic equivalent to the one in
LayerTreeHostCA. If we flush the layers synchronously when forceRepaint is called,when
WKPageForceRepaint returns we are guaranteed to have an up-to-date image, as the visible
tiles are also synchronously updated.

* UIProcess/API/qt/tests/qrawwebview/tst_qrawwebview.cpp:
(WebView::WebView):
(WebView::viewNeedsDisplay):
(WebView::frameLoaded):
(WebView):
(WebView::onRepaintDone):
(WebView::finishForceRepaint):
(WebView::finishFirstLayoutForFrame):
(tst_qrawwebview::doNoBackground1):
(tst_qrawwebview::doNoBackground2):
(tst_qrawwebview::doNoBackground3):
(tst_qrawwebview::run):
    The test for QRawWebView has been updated to use the WebKit2 ForcePaint API prior to
    generating the pixel results. This has exposed a timing bug in the test - setting the
    transparentBackground property of a page has to be done before it's created. This has
    been fixed in the test.

* WebProcess/WebPage/LayerTreeCoordinator/LayerTreeCoordinator.cpp:
(WebKit::LayerTreeCoordinator::forceRepaint):
(WebKit::LayerTreeCoordinator::performScheduledLayerFlush):
(WebKit):

Tools:

* MiniBrowser/qt/raw/View.h: Comment used old class name (WKView).
(View):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@122340 268f45cc-cd09-0410-ab3c-d52691b4dbfc
jsc: Parse options before creating global data
https://bugs.webkit.org/show_bug.cgi?id=90975

Reviewed by Filip Pizlo.

This patch moves the options parsing in "jsc" before the creation
of the JSGlobalData, so that --useJIT=no has a chance to take
effect.

* jsc.cpp:
(CommandLine::parseArguments): Refactor to be a class, and take
argc and argv as constructor arguments.
(jscmain): Move arg parsing before JSGlobalData creation.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@122341 268f45cc-cd09-0410-ab3c-d52691b4dbfc
REGRESSION (r116203): overflow sections don't have scrollbars
https://bugs.webkit.org/show_bug.cgi?id=90052

Reviewed by Simon Fraser.

This issue stems from RenderLayers with overlay scrollbars not being considered
self-painting.

After r120395 (follow-up of r116203), we ignore subtrees that have no self-painting layer for
painting. Normal scrollbars are painted by their renderer so they were properly painted. However
overlay scrollbars need to be painted by their RenderLayer as a separate phase (see bug 57057) so
they were not painted anymore. The fix is simple: make RenderLayer with overlay scrollbars
self-painting as they should have been in the first place.

Unfortunately no tests as I don't think we have a good way of testing overlay
scrollbars. Tested manually though on the super simple test case from the bug.

* rendering/RenderLayer.cpp:
(WebCore::RenderLayer::shouldBeSelfPaintingLayer):
Overlay scrollbars make the layer self-painting.

(WebCore::RenderLayer::updateScrollbarsAfterLayout):
Added a call to updateSelfPaintingLayer.

(WebCore::RenderLayer::styleChanged):
Moved the call to updateSelfPaintingLayer after recomputing the scrollbars to ensure proper behavior.
Added a comment underlining the reason.

(WebCore::RenderLayer::updateSelfPaintingLayer):
Renamed as it is now called during layout too.

* rendering/RenderLayer.h:
(RenderLayer): Updated after updateSelfPaintingLayer rename.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@122342 268f45cc-cd09-0410-ab3c-d52691b4dbfc
RenderView layer is marked as fixed position container in the scrolling tree if page scale != 1
https://bugs.webkit.org/show_bug.cgi?id=89216

Patch by Sami Kyostila <skyostil@chromium.org> on 2012-07-11
Reviewed by Simon Fraser.

Render layers with CSS transforms should become containers for any fixed
positioned descendants. However, because this check is done with
RenderLayer::hasTransform(), we also end up marking the RenderLayer for the
RenderView as fixed position container if a non-identity page scale factor is
used. This is because page scale is applied as a transform for that layer.

This breaks fixed position layers, because they become fixed relative to the
RenderView layer instead of outer scroll clip layer.

The fix is to avoid marking any root layers as fixed position containers.

No new test because the scrolling tree isn't currently testable.

* rendering/RenderLayerBacking.cpp:
(WebCore::RenderLayerBacking::updateGraphicsLayerGeometry):

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@122343 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[chromium] Use WEBKIT_IMPLEMENTATION == 1 for webkit_unit_tests
https://bugs.webkit.org/show_bug.cgi?id=90094

Reviewed by Adrienne Walker.

This patch adds the WEBKIT_IMPLEMENTATION = 1 define to
WebKitUnitTests.gyp. To get it to compile correctly, some string
and URL code was refactored and fixed, in particular GURL usage is
replaced with KURL usage.

* WebKit.gyp:
added WEBKIT_IMPLEMENTATION == 1 for unit test code when in shared library
added URLTestHelpers to exclusion in shared library build, because it depends on webkit_support

* WebKit.gypi:
added URLTestHelpers.h and .cpp to the build process

* WebKitUnitTests.gyp:
added WEBKIT_IMPLEMENTATION == 1 for unit test code when not in shared library.
note that in shared library build, RunAllTests.cpp does not have WEBKIT_IMPLEMENTATION == 1.

* public/WebDOMMessageEvent.h:
(WebKit::WebDOMMessageEvent::WebDOMMessageEvent):
* tests/AssociatedURLLoaderTest.cpp:
* tests/EventListenerTest.cpp:
* tests/FrameTestHelpers.cpp:
(WebKit::FrameTestHelpers::loadFrame):
* tests/FrameTestHelpers.h:
* tests/ListenerLeakTest.cpp:
(WebKit::ListenerLeakTest::RunTest):
* tests/PopupMenuTest.cpp:
* tests/RunAllTests.cpp:
* tests/URLTestHelpers.cpp: Added.
(URLTestHelpers):
(WebKit::URLTestHelpers::registerMockedURLFromBaseURL):
(WebKit::URLTestHelpers::registerMockedURLLoad):
* tests/URLTestHelpers.h: Copied from Source/WebKit/chromium/public/WebDOMMessageEvent.h.
(WebKit):
(URLTestHelpers):
(WebKit::URLTestHelpers::toKURL):
* tests/WebFrameTest.cpp:
* tests/WebPageNewSerializerTest.cpp:
* tests/WebPageSerializerTest.cpp:
* tests/WebViewTest.cpp:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@122344 268f45cc-cd09-0410-ab3c-d52691b4dbfc
HTMLFormCollection::item and HTMLPropertiesCollection::item should share code
https://bugs.webkit.org/show_bug.cgi?id=90932

Reviewed by Anders Carlsson.

Merged HTMLFormCollection::item and HTMLPropertiesCollection::item as HTMLCollectionWithArrayStorage::item,
which can be merged into HTMLCollection::item in a follow up patch.

Also moved the call to invalidateCacheIfNeeded into HTMLCollection::updateNameCache() as done in
HTMLPropertiesCollection.

In addition, moved the early bail out for when the base element doesn't have itemscope attribute from individual
functions to updateRefElements so that HTMLCollectionWithArrayStorage::item doesn't need to have this check.

* html/HTMLCollection.cpp:
(WebCore::HTMLCollectionWithArrayStorage::item): Added. It's based on HTMLPropertiesCollection::item but it only
has the single loop (as supposed to nested loops) as HTMLFormCollection doesn't have multiple items per element
in the array unlike HTMLPropertiesCollection. In addition, offsetInArray (was i in HTMLPropertiesCollection::item) is
incremented in each itemAfter due to this semantic difference in each itemAfter.
(WebCore::HTMLCollection::updateNameCache):
(WebCore::HTMLCollection::hasNamedItem):
(WebCore::HTMLCollection::namedItems):
* html/HTMLCollection.h:
(HTMLCollectionWithArrayStorage):
(WebCore::HTMLCollectionWithArrayStorage::HTMLCollectionWithArrayStorage):
* html/HTMLFormCollection.cpp:
(WebCore::HTMLFormCollection::HTMLFormCollection):
(WebCore::HTMLFormCollection::calcLength): Merged numberOfFormControlElements since it was only called here.
(WebCore::HTMLFormCollection::itemAfter): Added. HTMLFormCollection has exactly one item per element in the array
so we increment the offset in each iteration. Note that when we're continuing a search, we need to increment
the offset in order to avoid returning the same item.
(WebCore::HTMLFormCollection::updateNameCache):
* html/HTMLFormCollection.h:
(HTMLFormCollection):
* html/HTMLPropertiesCollection.cpp:
(WebCore::HTMLPropertiesCollection::HTMLPropertiesCollection):
(WebCore::HTMLPropertiesCollection::updateRefElements): Set m_hasItemRefElements true upfront since we never fail to
update ref elements. Bail out as soon as we cleared the m_itemRefElements when the base element doesn't have itemscope
content attribute.
(WebCore::HTMLPropertiesCollection::itemAfter): Added. We reset previousItem to null because the existing itemAfter
requires previousItem be null when we're moving to a new entry in m_itemRefElements.
(WebCore::HTMLPropertiesCollection::calcLength):
(WebCore::HTMLPropertiesCollection::cacheFirstItem):
(WebCore::HTMLPropertiesCollection::updateNameCache): Merged findProperties since this was the only caller.
(WebCore::HTMLPropertiesCollection::names):
(WebCore::HTMLPropertiesCollection::namedItem):
(WebCore::HTMLPropertiesCollection::hasNamedItem):
* html/HTMLPropertiesCollection.h:
(HTMLPropertiesCollection): Made updateRefElements public as it's called in HTMLCollectionWithArrayStorage::item.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@122345 268f45cc-cd09-0410-ab3c-d52691b4dbfc
[Gtk] allow building with css-filters
https://bugs.webkit.org/show_bug.cgi?id=90908

.:

Add support for css-filters in Source/WebCore/GNUmakefile.am
configure.ac

Patch by Arnaud Renevier <a.renevier@sisa.samsung.com> on 2012-07-11
Reviewed by Eric Seidel.

* configure.ac:

Source/WebCore:

Patch by Arnaud Renevier <a.renevier@sisa.samsung.com> on 2012-07-11
Reviewed by Eric Seidel.

Add support for css-filters in Source/WebCore/GNUmakefile.am
configure.ac

No functional change, so no new tests.

* GNUmakefile.am:

git-svn-id: http://svn.webkit.org/repository/webkit/trunk@122346 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Simplify the copying of JSC ARMv7's LinkRecord
https://bugs.webkit.org/show_bug.cgi?id=90930

Patch by Benjamin Poulain <bpoulain@apple.com> on 2012-07-11
Reviewed by Filip Pizlo.

The class LinkRecord is used by value everywhere in ARMv7Assembler. The compiler uses
memmove() to move the objects.

The problem is memmove() is overkill for this object, moving the value can be done with
3 load-store. This patch adds an operator= to the class doing more efficient copying.
This reduces the link time by 19%.

* assembler/ARMv7Assembler.h:
(JSC::ARMv7Assembler::LinkRecord::LinkRecord):
(JSC::ARMv7Assembler::LinkRecord::operator=):
(JSC::ARMv7Assembler::LinkRecord::from):
(JSC::ARMv7Assembler::LinkRecord::setFrom):
(JSC::ARMv7Assembler::LinkRecord::to):
(JSC::ARMv7Assembler::LinkRecord::type):
(JSC::ARMv7Assembler::LinkRecord::linkType):
(JSC::ARMv7Assembler::LinkRecord::setLinkType):
(JSC::ARMv7Assembler::LinkRecord::condition):


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@122347 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Unreviewed build fix, forgot to add URLTestHelpers.* when landing r122344

* tests/URLTestHelpers.cpp: Added.
(URLTestHelpers):
(WebKit::URLTestHelpers::registerMockedURLFromBaseURL):
(WebKit::URLTestHelpers::registerMockedURLLoad):
* tests/URLTestHelpers.h: Added.
(WebKit):
(URLTestHelpers):
(WebKit::URLTestHelpers::toKURL):

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